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

3. Происходит объединение всех таблиц ошибок с уже расставленными приоритетами.

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

5. Сравниваются полученные результаты и расставляются окончательные приоритеты.

Ошибки отдаются на решение специалистам по очереди согласно автоматически расставлен-ным приоритетам. Решенные ошибки из очереди удаляются. Вновь поступившие таблицы ошибок обрабатываются согласно шагам 1—3, азатем объединяются с уже имеющимися, и происходит перерасстановка приоритетов согласно

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Michael A. Olson. Sclccting and Implementing an Embedded Database System // IEEE Computer. Sept. 2000. P. 27-34.

2. Bowman I.T., Bumbulis P., Farrar D. et al. SQL Anywhere: An Embeddable DBMS // Bulletin of the IEEE Computer Socicty Technical Committee on Data

Engineering. Sept. 2007. Vol. 30, № 3.

3. Nystrom T.D., Hansson J., Norstrom C.

Embedded databases for embedded real-time systems: A component-based approach // Technical report / Dept. of Computer Science, Linkoping University, and Dept. of Computer Engineering. Malardalen University, 2002.

УДК 004.052.42

A.B. Ты рва, А. Д. Хомоненко

МЕТОД ПЛАНИРОВАНИЯ ТЕСТИРОВАНИЯ СЛОЖНЫХ ПРОГРАММНЫХ КОМПЛЕКСОВ НА ЭТАПАХ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ

Планирование и распределение ресурсов программных проектов — важная управленческая задача. Ее решение необходимо для повышения эффективности процесса разработки программного обеспечения. Задача планирования работ по проведению тестирования и отладки особенно актуальна при разработке сложных программных комплексов (СПК), к которым предъявляются высокие требования надежности. В частности, к таким СП К относятся многие комплексы автоматизированных систем на железнодорожном транспорте (АСУ процессом перевозок, технологическими процессами и т. д.).

При разработке СП К важно определить набор модулей, потенциально приводящих к отказу, чтобы выделить для них наибольшие ресурсы: квалифицированный персонал, большее время на тестирование и т. д. Чем раньше это будет сделано, тем больший будет достигнут эффект, так как, с одной стороны, исправление обнаруженных уже после выпуска профаммного средства ошибок обходится в десятки и сотни раз дороже, чем на этапе проектирования и реализации, с другой — статистика показывает, что наибольшее число ошибок локализовано вотносительно небольшом количестве отдельных модулей: в среднем 80 % ошибок приходится лишь на 20 % модулей.

1. Общее описание предлагаемого метода планирования тестирования

Предлагается метод планирования работ по тестированию СП К, развивающий подход [2], в котором СП К представляется в виде совокупности т программных модулей. Отдельные модули подвергаются автономной отладке и тестированию для оценивания и повышения характеристик их надежности (вероятности безошибочного функционирования). Далее на основе результатов тестирования (число зафиксированных отказов, интенсивность отказов каждого модуля) и предположения об экспоненциальном характере распределения времени между отказами по модели Джелинского — Моранды находятся вероятности безотказной работы каждого модуля. Полученные оценки служат для определения потенциально приводящих к отказу модулей, последовательности отладки (в порядке увеличения вероятности безотказной работы) и момента окончания отладки.

Применение названного подхода возможно на поздних этапах цикла разработки программных средств (ПС), когда готов программный код, началась автономная отладка и собран достаточный объем статистики по отказам модулей СПК для использования моделей надежности. Используемая стратегия не является наилучшей в смысле минимизации трудозатрат при тестировании и отладке СПК, так как модуль, у которого вероятность безошибочного функционирования наименьшая, не обязательно оказывает наибольшее

влияние на снижение вероятности безошибочной работы СП К в целом.

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

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

обеспечивает учет вклада каждого модуля в надежность СПК в целом на основе прогноза времени и вероятности его исполнения;

может применяться на всех этапах цикла разработки СПК;

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

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

11рименение предлагаемого метода планирования испытаний схематично показано на рис. 1: приведены два проекта по разработке ПС. В проекте 1 завершены этапы проектирования (собраны проектные метрики сложности из и М Ь-ди-аграмм), кодирования и тестирования (см. разд. 2). По статистике ошибок при тестировании модули СПК разделяются на два класса — содержащие и не содержащие ошибки. Затем строится модель прогноза надежности — зависимость вероятности проявления ошибки в модуле от значений проектных метрик сложности (см. разд. 3). В проекте 2 выполнены только ра-

Проектирование Реализация Тестирование

иМЬ-диа граммы Коды программы Статистика ошибок

Проектныв метрики сложности

Проект 1

Модель прогноза надежности

1)М1.-диаграммы

I I

Проектные метрики сложности (

Эксперт

Определение ненадежных модулей на раннихэтапахЖЦ

Стохастический граф СПК.

времена исполнения модулей • Проект 2 [_.

1

Рис. 1. Использование стратегии планирования тестировании СПК

боты этапа проектирования и собраны проектные метрики сложности из UML-диаграмм. По построенной модели прогнозируются потенциально ненадежные модули. Использование экспертных заключений о характере распределения времени исполнения отдельных модулей и стохастического графа СП К позволяет выполнить оценку степени влияния каждого модуля на надежность СП К в целом и, следовательно, оптимизировать распределение ресурсов тестирования, построить план тестирования (см. разд. 4).

Сравнение результатов использования предлагаемой стратегии с известными аналогами при планировании тестирования и планировании проведения тестирования СПК показывает, что достигается повышение эффективности тестирования и рост надежности программного продукта (см. разд. 5).

2. Жизненный цикл

В процессе разработки СПК проходит несколько этапов. Вне зависимости от модели жизненного цикла(водопадная,спиральная,экстремальное программирование и др.) обычно выделяют следующие этапы: анализ требований, проектирование, реализацию, тестирование и отладку, внедрение, эксплуатацию и сопровождение. На каждом из этапов разрабатываются артефакты, которые могут служить источником измерений для последующего моделирования и планирования проекта. Например, на этапе проектирования разрабатывается архитектура СПК и подсистем, структур данных и т. д. При использовании широко распространенного унифицированного языка моделирования UML (Unified Modeling Language) на этапе проектирования создается набор диаграмм: диаграмма классов, состояний, вариантов использования и др. Эти диаграммы могут быть использованы для сбора измерений и прогноза надежности компонентов системы (см. разд. 3).

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

На последующих этапах жизненного цикла собирается статистика об отказах СПК (в процессе отладки и эксплуатации), и для прогноза

надежности становится возможным применение различных моделей надежности: Джелинского — Моранды, Мусы, Гоэл — Окумото и других.

3. Метрики сложности

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

В литературе большое внимание уделяется вопросам разработки, проверки и применения метрик сложности программных средств, доступных на этапе проектирования (обзор подходов можно найти в [7, 8j). Для решения описываемых в данной статье задач предлагается использовать набор объектно-ориентированных метрик, предложенных в [5,6J. Их выбор обоснован следующими соображениями:

метрики основаны на объектно-ориентиро-ванном подходе и применимы (с небольшими изменениями) для различных языков программирования (С + + , С#, Java и др.);

метрики теоретически и математически обоснованы [5,6], хорошо известны и практически применимы [8J;

исследована и подтверждена возможность применения для раннего обнаружения модулей, потенциально приводящих к отказу [4, 5,7, 8J;

сбор значений метрик сложности не требует больших трудозатрат и может быть автоматизирован [8J, втом числе при сборе изпроектныхдо-кументов, разработанных с использованием унифицированного языка моделирования UML — фактически промышленного стандарта проектирования.

На этапе проектирования СПК целесообразно использовать следующие метрики сложности |4-7j:

количество классов, использующих данный класс (в качестве атрибута, параметров методов, локальных переменных и др.) — coupling between object classes (СВО);

количество методов и функций, которые используются для обработки поступающих событий — response for a class (RFC);

длину наибольшего пути иерархии наследования — depth of inheritance tree (DIT);

количество классов-наследников — number of children (NOC);

взвешенное количество методов класса — weighted methods per class (WMC);

разность между количеством пар методов класса, использующих общие объекты, и количеством пар методов, не использующих общие объекты — lack of cohesion in methods (LCOM);

количество атрибутов классов — total number of attributes (N Al);

набор метрик, определяющих взаимодействие между классами: количество классов с параметрами методов типа данного класса — others class-method export coupling (ОСМЕС), количество классов-друзей с атрибутами типа данного класса — friends class-attribute export coupling (FCAEC) и другие [5,7].

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

где х, — значение метрики сложности; Р; — коэффициент.

Параметры модели р, находятся методом максимального правдоподобия [9]. Например, для статистики об п модулях функция правдоподобия ¿(Р) имеет вид

где у, = I, если в /'-м модуле была обнаружена ошибка, yt=0, если иначе; х, - вектор значений метрик сложности для /-го модуля; р — вектор параметров модели.

Значения параметров модели определяет вектор р, при котором функция правдоподобия максимальна. Для нахождения вектора численными методами решается система уравнений [9|:

Хху[у,-я(дс,.)] = 0.

. j

В [7] приводятся пример и результат такого моделирования, для чего авторами проанализировано готовое коммерческое приложение, программные модули классифицированы как ненадежные (при тестировании обнаружены ошибки) и надежные, определены проектные метрики сложности и построена регрессионная модель:

1 + е ' 3'97+0-464NAM'470CMEC+1'06DIT)'

Модели, аналогичные описанной, могут быть построены и для других наборов метрик сложности, в том числе на поздних этапах жизненного цикла. Например, на этапе реал изации для анализа программного кода могут быть использованы следующие метрики: LOC (Lines of code), метрики Холстеда и МакКейба, функциональные точки и др. (обзор метрик сложности и примеры их использования для моделирования надежности можно найти в [10]). Как отмечалось, после начала отладки, когда появляются данные о распределении отказов, становится возможным учитывать в прогнозе также оценки моделей надежности.

4. Математическая модель планирования тестирования

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

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

Таким образом, для расчета вероятности я] наличия ошибки в /'-м модуле при функционировании в СП К предлагается использовать оценки его надежности л,, вероятности <7, выполнения модуля при работе в СП К и среднего времени выполнения /,:

л; = /Гл,<7

Для расчета времени выполнения модулей СП К представляется в виде сети массового обслуживания, узлами которой выступают модули СП К, а ветвями — вызовы отдельных модулей с различными вероятностями. Затем вычисляются первые моменты времени прохождения заявки между модулями за бесконечное число шагов. Для этого строится матрица у( .у) (2,3]:

Ро2

Poo Pq\ РюУАЯ РиУ\(1) РпУi<*>

Р1.0У1.О) РпУî» Р1.2У1Р)

PlL^

' L.L

I У№

ги 1.0

,

где Pjj — вероятность вызова j-го модуля после исполнения /-го; у ¡(s) — преобразование Лапласа — Стилтьеса (ПЛС) распределения времени исполнения /-го модуля.

Чтобы определить время выполнения СП К, необходимо рассмотреть матрицу, элементами которой являются ПЛС функции распределения перехода из одного модуля в другой за бесконечное число шагов K(s):

V

где / — единичная матрица;

Vi/s) =Aj,{s)/D

где Aß(s) — алгебраическое дополнение элемента (ij) матрицы v(s); D(s) — определитель матрицы

Ф).

Среднее время выполнения СПК

Т = —

ds

Среднее время выполнения /-го модуля

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

Вероятность выполнения у'-го модуля ^определяется путем решения системы линейных уравнений:

1 V'- P'J

где Л, — среднее время выполнения /'-го модуля; Рц — вероятность перехода из /-го модуля ву'-й.

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

ошибок п\). Например, если известно общее время модульного тестирования СПК т, то расчет времени тестирования /'-го модуля т, производится по следующей формуле:

Ту =ТЯ,-.

Модель, описанная в предыдущем разделе, запрограммирована с использованием математического пакета MATLAB R2007B, инструментального средства символьных вычислений Symbolic Math Toolbox.

5. Оценка эффективности предлагаемой стратегии планирования проведения тестирования СПК

Для оценки эффективности предлагаемого подхода произведен расчет прогнозируемой вероятности безотказной работы СПК после проведения тестирования в течение времени, рассчитанного по двум моделям: предлагаемой и описанной в [2]. Поскольку модель [2] не предназначена для применения на этапе проектирования, для сравнения использовалась модифицированная модель. В ней при распределении времени тестирования между модулями учитываются полученные по метрикам сложности оценки надежности л, и не учитываются вероятности исполнения />, что соответствует процедуре тестирования критичных модулей, описанной в [2]. Для расчета вероятности безотказной работы 1-го модуля Riза среднее время функционирования использована модель Мусы [1]:

Я=е

Здесь Т] — средняя наработка на отказ после проведения тестовых испытаний,

4 в1|-1-1-1-1-1-1-1-1-1-

'О 5 М 1» 20 гъ 38 К 40 « 60

Рис. 2. Зависимость эффективности использования модели от времени тестирования

T.=T;eM,T;,

где Т{ — средняя наработка на отказ в начале испытаний; С— коэффициент сжатия тестов; т, — время испытаний; Л/, — общее число дефектов, которые могут произойти за время испытаний zr

При расчетах были использованы следующие предположения:

средняя наработка на отказ в начале испытаний Т/ обратно пропорциональна оценке вероятности ошибки в модуле, полученной по значениям метрик сложности;

зависимость общего количества ошибок в модуле Л/,от оценки вероя гности ошибки в модуле имеет вид сигмоидной функции;

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

Вероятность безотказной работы СП К может быть вычислена с использованием формул (6) — (9), если заменить преобразование Лапласа — Стилтьеса у, (s) вероятностью безотказной работы /'-го модуля втечение среднего времени функционирования р ,{?,).

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

Под эффективностью понимается отношение (К-/*)/Л, где — прогнозная вероятность безотказной работы СП К после тестирования втечение времени, рассчитанного с использованием предлагаемой стратегии, /?' —с использованием стратегии, описанной в [2].

Зависимость эффективности использования предложенной модели от времени тестирования приведена на рис. 2. Анализ графика показывает, что предложенная модель эффективнее аналогов. Наибольший эффект достигается при относительно небольшом времени тестирования и составляет около 5 %.

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

СПИСОК ЛИТЕРАТУРЫ

1 Муса Дж. Д. Измерение и обеспечение на- 2. Смагин В.А. Техническая синергетика,

дежности программных средств//ТИИЭР. 1980. Вероятностные модели сложных систем. СПб., Т. 68, № 9. 2004.

3. Смагин В.А., Бубнов В.П., Филимонихнн Г.В.

Расчет вероятностно-временных характеристик пребывания задач в сетевой модели массового обслуживания // Изв. вузов. Приборостроение. 1989. Т. XXXII, № 2.

4. Basili V.R., Briand L.C., Melo W.L. A validation of object-oriented design metrics as quality indicators // IEEE Transactions on Software Engineering. Oct. 1996. Vol. 22, Issue 10.

5. Briand L., Devanbu P., Melo W. An Investi-gation into Coupling Measures for С ++ // Proc. of the 1997 (19th) Intern. Conf. on Software Engineering. 17-23 May 1997.

6. Chidambcr S.R., Kemerer C.F. A metrics suite for object oriented design// EEE Transactions on

Software Engineering. Jun 1994. Vol. 20. Issue 6.

7. Kl-Kmam K., Melo W., Machado J.C. The prediction of faulty classes using object-oriented design metrics // Journal of Systems and Software. 1 Febr. 2001. Vol. 56, № 1.

8. Genero M., Piattini M., Caleron C. A survey of metrics for UML class diagrams// Journal of Object Technology. 2005. Vol. 4.

9. Hosmer D.W., Lemeshow S. Applied Logistic Regression. 2nd ed. New York: Wiley, 2000.

10. Khoshgoftaar T.M., Munson J.C., Bhat-tacharya B.B., Richardson G.D. Predictive Modeling Techniques of Software Quality from Software Measures// IEEE Transactions on Software Engineering. Nov. 1992. Vol. IH, № 11.

УДК 004.4 Б 1.2

E.B. Соколов, М.Ю. Кудрин, А.Г. Тормасов

ОРГАНИЗАЦИЯ СНИМКА ПАМЯТИ НА ОСНОВЕ пк-СХЕМЫ ПРИ НАЛОЖЕНИИ ОГРАНИЧЕНИЙ ТЕМПА И ПОРЯДКА ДОСТУПА

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

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

Он позволяет нескольким процессам, называемым "читателями", считывать "непротиворечивую" картину области памяти, доступную нескольким потокам. В это время другие процессы — "писатели" могут обновлять память. Считывание и запись могут производиться одновременно.

Интерфейс работы с памятью состоит из двух функций: Е^а1е(т11, Туа1ие) — обновляетзна-

w

R I-

Часы продать

чение одного блока памяти; Т[ J Scan() — делает снимок памяти.

В работе (3] приводится wait-free алгоритмы снимка памяти. Но в таком понимании есть существенный недостаток — возникновение "противоречивой" информации. Рассмотрим пример на рис. 1.

Есть два потока, которые обмениваются информацией через общую ячейку памяти. Ячейки памяти содержат в себе буквы сообщения. Допустим, передатчик передает сообщение "часы продать", пока читатель считывал фразу, она изменилась на "духи купить". И вместо последнего слова "продать" будет считано "купить". Таким образом, читатель получит неправильное сообщение — "часы купить".

Духи купить

Часы ...

... купить

Рис. 1. Пример возникновения противоречивой информации