CC BY
62
Информационные системы и программное обеспечение
УДК 004.5:004.738.52:51-78
А.Н. Кузнецов, Е.В. Пышкин
алгоритм сравнения нотных фрагментов при поиске музыкальной информации по образцу мелодии
Интернет предоставляет своим пользователям намного больше возможностей, чем просто просмотр текста на web-страницах. Текущая спецификация HTML5 предусматривает различные средства внедрения мультимедийных и интерактивных элементов. Однако поиск информации по-прежнему осуществляется поисковыми машинами, ориентированными на поиск по ключевым словам. Это приводит к тому, что некоторые ресурсы в Интернете найти практически невозможно. К таким ресурсам можно отнести аудиозаписи, видеоролики, изображения и другие мультимедийные объекты, не содержащие в себе текстовой информации. Несмотря на то, что обычно такие ресурсы сопровождаются текстовыми аннотациями, содержащими информацию об авторе, названии, жанре и т. п., найти ресурс именно по его содержимому (например, напев мелодию или описав, что изображено на картинке), крайне затруднительно.
Описанные трудности обусловлены, в первую очередь, тем, что бинарный формат мультимедийных данных не допускает погрешностей интерпретации, а естественный язык (на котором осуществляется запрос) не позволяет точно описать искомый объект. Свой вклад вносит и память человека, являющаяся источником образов для поиска. Высокочастотная информация запоминается намного хуже, чем низкочастотная, например, легко запомнить оттенок своего письменного стола и его форму, сложнее запомнить узор и крупные сколы или царапины, если они есть, и крайне сложно запомнить расположение мелких царапин и прочих дефектов.
Невозможность прямого сравнения содержимого бинарного файла с пользовательским запросом вынуждает разработчиков поисковых систем
извлекать из бинарного файла метаданные и производить поиск по этим метаданным. В данной ситуации существенным является способ извлечения метаданных: ручной, автоматизированный или автоматический. Автоматический способ извлечения наиболее сложный, поскольку связан с проблемой распознавания образов; ручной -наиболее медленный. Перспективным представляется решение, которое сможет повторно использовать огромный объем данных, обработанных ранее (в т. ч. вручную) пользователями различных сервисов. Поясним последнее утверждение на примере музыки.
Музыка занимает особое место в многообразии мультимедийного содержимого. В отличие от других видов искусства, в музыке изначально предполагается, что композитором и исполнителем могут быть разные люди, а значит, необходим формальный язык передачи музыкальной информации от композитора к исполнителю - таким языком и являются ноты. Этот факт может быть использован при поиске следующим образом. Музыка обычно хранится в каком-либо популярном аудио-формате (например, тр3, wma и т. п.). На сайтах, где размещаются музыкальные записи, также хранится имя исполнителя, название композиции, альбома, жанр. Заметим, что любители музыки часто перекладывают сочинения любимых авторов в ноты, сопровождая их теми же аннотациями. В результате мы получаем возможность работать не с бинарными музыкальными файлами, а с нотным текстом - формальным представлением содержимого бинарного файла. Составив метаданные на основе нотной записи, мы обеспечиваем другим пользователям возможность поиска композиций не по названию, а по ее содержимому.
Предмет исследования данной статьи - методы и алгоритмы сравнения музыкальных фрагментов, а также поиск музыки как таковой.
Поиск музыки: проблемы и подходы
Рассмотрим основные сценарии поиска музыки.
Сценарий 1: «Я помню автора/название/ альбом». Данный сценарий описывает ситуацию, когда пользователю известны частичные сопроводительные данные к композиции. В этом случае сложностей при поиске практически не возникает, т. к. практически любой Интернет-магазин, специализирующийся на музыке, имеет функцию предпрослушивания с возможностью поиска по автору или названию композиции.
Сценарий 2: «Я помню слова». Если речь идет о песне, и пользователь знает некоторые слова, то задача сводится к текстовому поиску, обеспечиваемому любой поисковой машиной.
Сценарий 3: «У меня есть записанный фрагмент». Нередки случаи, когда у пользователя есть фрагмент записи (с концерта, радиотрансляции или из телевизионной передачи), при этом сопроводительных данных к композиции нет. В подобной ситуации можно рассматривать два основных решения. Во-первых, пользователь может воспользоваться помощью других людей, например, поместив отрывок на тематических форумах (таких, как feelbeat.my.ru, night.kharkov.ua или www.tonnel.ru). Такой подход работает медленно и иногда не приносит результата. Во-вторых, можно применить специализированные поисковые машины, например, AudioTag.info, Tutanic, Magic MP3 Tagger, Picard, TrackID, ShazamID. Данный подход позволяет получать список результатов быстро, однако этот список может оказаться огромным и при этом вообще не содержать искомой композиции.
Сценарий 4: «Я помню мелодию». Данный сценарий является наиболее сложным, поэтому прежде чем непосредственно перейти к проблеме поиска по образцу мелодии, подведем промежуточные итоги.
Анализируя описанные выше сценарии, можно заключить, что первые два сценария являются разновидностями текстового поиска с применением обычных текстовых поисковых машин. Проблема, описанная в третьем сценарии, может быть решена с использованием специализированных музыкальных поисковых машин, в основу работы которых, как правило, положено сравнение
так называемых акустических отпечатков сравниваемых фрагментов (acoustic fingerprint, audio fingerprint). Для аудиофрагмента фиксированной длины вычисляются его спектральные характеристики с учетом психоакустических особенностей восприятия звуков человеком. Вычисленные характеристики записываются в виде вектора (spectral fingerprint). Затем этот вектор сравнивается с образцами подобных векторов, хранящихся в базе известных композиций [1].
Данный метод широко используется различными коммерческими и бесплатными программами для определения исполнителя и композиции по записанному фрагменту. Известны также открытые реализации, например, Library Open Fingerprint Architecture, с открытой для публичного пользования базой данных образцов. Размер образца, по которому осуществляется поиск, обычно составляет около трех секунд, поэтому здесь речь не идет о поиске по мелодии или даже по фрагменту мелодии.
Наряду с личными потребностями пользователей необходимость поиска по фрагменту мелодии может быть обусловлена разнообразными причинами как коммерческой, так и некоммерческой природы.
• В музыкальном магазине часто встречается ситуация, когда покупатель хочет приобрести запись, зная только мелодию из композиции, но не зная названия, автора, исполнителя и т. п. Идентификация композиций, напетых пользователем, может быть очень полезной функцией для увеличения продаж магазина.
• Композиторы часто цитируют в своих произведениях как свои ранние произведения, так и отрывки из произведений других авторов, народные или религиозные мелодии. Возможность поиска фрагментов, похожих на заданный образец, может помогать музыковедам в их исследованиях о развитии композиторского творчества, взаимовлиянии композиторов, школ, культур, временных и национальных контекстов.
• Музыкальные поисковые машины могут способствовать решению проблем в области авторских прав [2].
Поиск, основанный на образце мелодии
Рассмотрим основные возможности поиска композиции по образцу мелодии.
• Напеть мелодию, записать в файл и воспользоваться тематическим форумом.
• Напеть/насвистеть мелодию и отдать ее на идентификацию специальной программе, например, сервисам на www.midomi.com, www. musipedia.org.
• Настучать мелодию (ритм). Данный подход используется сервисами на ritmoteka.ru, www.bored.com/songtapper,www.musipedia.org. Этот метод довольно прост, но все же малоэффективен, поскольку рисунков ритма, в действительности, значительно меньше, чем сочиненных композиций. То есть даже если ритм будет введен правильно, велика вероятность, что придется изучать список из нескольких тысяч наименований.
• Написать ноты для мелодии и передать их в специализированную поисковую машину (например, www.midomi.com или www.musipedia.org).
• Наиграть мелодию на виртуальном инструменте (www.musipedia.org).
Более детальный обзор поисковых машин с описанием принципов их работы можно найти в [2].
С точки зрения разработчика, напетые пользовательские фрагменты могут быть приведены к нотам, что сводит задачу к поиску по нотам. В [3] сформулирована следующая последовательность шагов сравнения аудиофрагментов:
1) вычисление высоты тона;
2) вычисление границ нот;
3) извлечение мелодии из последовательности нот;
4) сравнение извлеченной мелодии с образцами из базы данных.
Более общий подход (query-by-humming) предполагает пропуск шагов 2 и 3. Извлеченные на первом шаге параметры (не обязательно высота тона) сравниваются на четвертом шаге в пространстве этих параметров. Обычно рассматривается двумерное пространство с координатами «тон» и «время». Тон может представлять собой как направление изменения частоты (т. е. в музыкальной терминологии - высоты) «U, D, R» (что означает соответственно «вверх», «вниз» или «без изменения») или «u, U, d, D, R» («слабо вверх», «сильно вверх», «слабо вниз», «сильно вниз», «без изменения»), так и абсолютное значение или абсолютное/относительное изменение частоты звука. Квантование времени и частот можно выбрать таким образом, что представление фрагмента в пространстве «тон-время» окажется эквивалентно нотному представлению [4].
Анализ алгоритма Earth Mover's Distance (EMD)
В реализации музыкальной поисковой машины невозможно обойтись без алгоритма сравнения музыкальных фрагментов. Используемый алгоритм оказывает непосредственное влияние на качество поиска, определяемое как релевантностью результатов, так и скоростью их получения.
Вне зависимости от конкретной реализации все алгоритмы можно разбить на четыре большие группы, сравнивающие: 1) монофонический фрагмент с монофоническим; 2) монофонический с полифоническим; 3) полифонический с монофоническим; 4) полифонический с полифоническим.
Все известные нам алгоритмы работают с представлением музыки так или иначе приводимом к piano-roll. В [5] производится сравнение некоторых алгоритмов между собой, из которого можно сделать вывод, что проблема формального сравнения монофонических фрагментов в настоящий момент проработана хорошо.
В общем виде идея алгоритма проста: мелодия представляется в двумерном пространстве (одна из степеней свободы - высота тона, либо производная от этой величины; другая - время, абсолютное или логическое, или производная от этой величины). Затем вводится функционал f: a е P, Ъ е P ^ c е R , где а, Ъ е P - отрезки piano-roll (характеризуются временем наступления события, высотой тона и длительностью события), c е R - вещественные числа. С помощью введенного функционала вычисляется расстояние между двумя множествами: искомым шаблоном и шаблоном из базы как сумма расстояний между соответствующими отрезками, либо как наименьшая из сумм при некоторых ограничениях на транспозицию отрезков и масштабирование осей (задача оптимизации). Вычисленное расстояние используется для определения порядка возвращаемых результатов.
Различные алгоритмы отличаются, в первую очередь, введенным функционалом. Такой подход к сравнению монофонических фрагментов кажется вполне естественным. На практике его часто применяют и для полифонических фрагментов. Хотя в целом такие алгоритмы часто оказываются эффективными и для сравнения монофонического образца с полифоническим, существует множество ситуаций, когда две совершенно раз-
Рис. 1. Нотный фрагмент и его представление в piano-roll
ные монофонические мелодии оказываются одинаково близкими к полифонической. Причины возникновения подобных ситуаций поясним на примере известного алгоритма EMD.
В качестве полифонического фрагмента возьмем отрывок из произведения прелюдии ми минор А. Скрябина (соч. 11 №4). На рис. 1 приведен фрагмент нотной записи и соответствующее представление в формате piano-roll.
Рассмотрим два монофонических фрагмента, представленные на рис. 2.
Очевидно, что первый фрагмент (назовем его фрагмент A) является частью аккомпанемента, в то время как второй (фрагмент B) - мелодией.
Постановка задачи EMD в терминах линейного программирования имеет следующий вид. Пусть A = {ax, a2, ..., am} - множество взвешенных точек, таких, что at = {(xi, wi)}, i = 1, ..., m , где x e Rk - координата точки, w. e R + u {0} -
m
масса точки. Пусть W = Z wi - суммарная масса
j=1
множества A. Пусть даны два множества взвешенных точек A, B и функция расстояния d. Обозначим как f величину перемещаемой массы из xi в yj (на расстояние dv). Если Wи U- суммарные веса множеств A и B соответственно, то множе-
ство всех возможных перемещений масс F = [ f] задается следующими ограничениями [6]:
fj > 0, i = 1, ..., m; j = 1, ..., n
n
Zf - w, i =1..., m
j=0
f — u , j = 1, ..., n
ij j
ij
i=0
ZZ fj = min(W, U).
j=о i=0
Расстояние EMD между двумя множествами вычисляется как минимальное значение:
п т
EMD( A, B) =
min
¿—¡j=0L.-f i=0J ij ij
fd
ij ij
шт(Ж, и)
Очевидно, что поскольку искомый отрезок мелодии В является подмножеством полифонического фрагмента, то существует такой набор перемещаемых масс X, что дистанция будет равна нулю для любых /, у. Аналогичные результаты справедливы для фрагмента А. Получается, что EMD( А, О) = EMD( В, О) = 0.
Рассмотренная выше ситуация может возникать на практике довольно часто. Вместо фрагмента А можно было выбрать произвольное подмножество нот полифонической мелодии и получить значение ноль для алгоритма EMD.
А
B
Рис. 2. Фрагменты аккомпанемента и мелодии, представленные в piano-roll
С точки зрения человека дистанция, конечно, должна быть существенно больше нуля.
Суть проблемы в том, что алгоритм формально ищет ноты, общие для двух фрагментов. Человек же ставит оценку, основываясь не на нотах, а на восприятии. Такое отличие человеческой оценки схожести от машинной производит на свет множество ложных срабатываний: если фрагменты похожи, у них будут общие ноты (интервалы), но не все фрагменты с общими нотами похожи (как это видно в рассмотренном выше примере).
Модификация алгоритма EMD
Цель предлагаемой модификации заключается в уменьшении числа ошибок, подобных продемонстрированным в предыдущем разделе. Основная идея подхода состоит в расширении оценки EMD за счет введения третьей координаты, отражающей восприятие музыки человеком. Эта координата г будет влиять лишь на вычисление расстояния ё между нотами, но не на массу. Далее будем называть этот алгоритм EMD3D.
Трудно принять во внимание все особенности человеческого восприятия, но некоторые из них могут быть учтены довольно просто.
Учет громкости. Пусть в любой момент времени одновременно звучит не более п нот. Тогда все ноты, звучащие в один момент времени, можно ранжировать и ввести значение е {0, 1, ..., п -1}, где - показатель громкости, 0 - самая громкая.
Если пользовательский запрос монофонический, то показатели громкости всех нот в запросе автоматически оказываются равными нулю. При сравнении двух нот одинаковой длительности и высоты дистанция ё будет большей нуля, если показатели громкости не совпадают. Громкая нота (с показателем громкости, равным нулю) будет заглушать остальные, поэтому она будет с большей вероятностью воспроизведена пользователем, который вводит монофонический фрагмент со слуха.
Усложняя модель, можно ввести коэффициент затухания громкости; очевидно, для каждого инструмента он будет свой.
Учет повторения ноты. Обратимся еще раз к фрагменту прелюдии на рис. 1. Очевидно, что повторяющаяся нота си первой октавы оказывает влияние лишь на красочность восприятия, но не на саму мелодию. В общем случае, если мы удалим повторяющиеся ноты, то музыкальное произ-
ведение изменится, но не так сильно, как если бы мы удаляли неповторяющиеся ноты.
На основе этого наблюдения можно ввести параметр г е{0,1}, характеризующий значимость ноты для восприятия на основе ее повторения. г = 0 , если непосредственно перед нотой не звучала она же, г = 1 - если звучала.
По крайней мере, два случая представляют собой исключения:
единственная звучащая нота будет слышна хорошо (г = 0 ), даже если она повторяется;
нота после паузы будет звучать отчетливо (Г = 0).
Это же утверждение в более общем виде лежит в основе методов выделения мелодии из полифонического произведения на основе энтропии музыкального трека [7].
Ноты в верхнем или нижнем голосе. Обычно (но далеко не всегда) мелодию образуют либо ноты самого верхнего голоса, либо - самого нижнего. Для учета этой особенности введем параметр т1 е {ОД}, такой, что т1 = 0 , если нота является самой высокой или самой низкой в созвучии, в противном случае т1 = 1.
Это же утверждение лежит в основе skyline-алгоритмов выделения мелодии [8]. Хотя этот параметр, по-видимому, является наиболее спорным, его учет часто оказывает значимый положительный эффект на качество работы алгоритма сравнения.
Интегральная оценка сходства образцов, используемая алгоритмом EMD3D. Учитывая все сказанное выше, формулировка алгоритма оценки сходства образцов EMD3D в терминах линейного программирования имеет следующий вид. Пусть даны два множества:
А = {а^..., ат};Я = {Ъ^Ъп^ таких, что
а =(ха,, ж); Ъ =(, ж, X
где ха^, хЪ] е Я3 и , е Я + и {0} .
Обозначим индексы а1 и ЪJ звездочкой (*). Вес ж, приравняем значению длительности ноты (в четвертях, миллисекундах и т. п.). Координата ноты х, = {?,,р,,г,}является трехмерным вектором, где I, - время начала звучания; р, - значение высоты тона; г, - значимость ноты, вычисляемая с учетом перечисленных выше факторов:
г, = с1у, + с2 г, + с3т,, где V, е N - показатель громкости; г, е {0,1} -
признак повторения; т* е {О, 1} - признак самого высокого/низкого голоса; с1, с2, с3 - масштабирующие коэффициенты (использовались значения с1 = 2, с2 = 1, с3 = 0,5).
Для оценки сходства образцов используется выражение, аналогичное выражению, используемому в EMD:
EMD( A, B) =
n m р i
min > > f..a.. X eF ¿—tj=oZ—i i=0Jj !j
min(W ,U) c теми же ограничениями:
f > 0, i= 1, ..., m; j = 1, ..., n
> fj < ^, i = 1, ...,
m
j=0
> f j < uj, j=1
i=0 n m
>> fj = min(W, U),
j=0 i=0
где - расстояние в трехмерном евклидовом пространстве между координатами нот , р1,2 1)
и (tj, Pj, ):
d.. =
Несложно продемонстрировать, что при таком представлении музыки в трехмерном пространстве расстояния EMD3D(Л,О) и EMD3D(B,О) (для примера, рассмотренного выше) будут разными, и мелодия (фрагмент В) оказывается ближе к оригиналу, чем фрагмент аккомпанемента:
EMD3D(Л, О) = 4,17, EMD3D(B, О) = 0,56.
Дополнительные критерии поиска
Поиск по образцу - важный элемент функциональности, однако поисковая машина не должна ограничиваться исключительно этим. Образец воспроизводится пользователем с некоторой точностью, т. к., например множество мелодий из трех нот равной длительности составляет 883 = 681 472 элементов для стандартного пианино или 123 = 1728 элементов, если все ноты лежат в пределах одной октавы. Получается, что вероятность ошибки в определении мелодии велика хотя бы из-за большого количества элементов множества мелодий из п нот. Более того, размер множества растет со скоростью показательной функции. Поэтому важно также использовать при поиске информацию, более достоверную статистически, например, набор музыкальных инструментов. В то время как множество мело-
дий из n нот составляет 88n элементов, стандарт General MIDI допускает только 128 инструментов, не считая ударных. Вероятность ошибки в определении инструмента значительно меньше, поэтому информация об инструменте более надежна, чем, скажем, мелодия. Аналогично можно выделить и другие параметры: музыкальный инструмент, тональность, размер, темп и др. В случае если пользователь испытывает затруднения при определении точного значения параметра, предоставляется возможность выбора нескольких инструментов, тональностей, размеров.
Всю описанную выше информацию для поиска можно легко извлечь из midi-файлов, которые предлагается использовать как основной источник информации. Сами midi-файлы могут быть автоматически найдены в сети по расширению. Базовым алгоритмом для сравнения фрагментов предлагается использовать EMD3D, который может быть расширен с учетом дополнительных критериев восприятия.
Отметим, что внедрение и даже широкое применение поисковой системы еще не является конечной точкой исследований. На этапе активного использования поисковой системы можно собирать статистическую информацию, которую затем применять для динамического изменения значимости нот в шаблонах в базе.
Например, сместим плоскость Z на число x и введем четвертое слагаемое p t е [-1;1] - статистическую значимость. Тогда значимость ноты:
Zi = x + cv + c2 r + c3mi - xpt .
Начальное значение p = 0. В процессе работы пользователей с поисковой системой это значение может изменяться в пределах диапазона [-1;1]: в сторону положительных значений для нот, по которым пользователь идентифицировал композицию, в сторону отрицательных значений для нот, не имеющих отношения к мелодии. Чтобы обеспечить работоспособность такого подхода, необходимо иметь возможность получать от пользователя отзыв, нашел ли он композицию или нет (например, добавив в интерфейс кнопки «Это то, что я искал!» и «Это совсем не похоже на то, что я искал!»). На этапе составления базы можно повторно использовать знания, накопленные такими проектами, как musipedia.org, midomi.com и пр. Базы данных этих проектов уже содержат тысячи записей мелодий (монофонических фрагментов), которые можно использовать для вычис-
Правила для вычисления значимости нот
Факторы Правила
Нота самая громкая в созвучии 0 1 0 0 1 1 0 1 0 0 1 1 *
Нота повторяется 0 0 1 1 1 1 0 0 1 1 1 1 *
Нота сразу после паузы * * 0 1 0 1 * * 0 1 0 1 *
Единственная звучащая нота 0 0 0 0 0 0 0 0 0 0 0 0 1
Нота самая высокая/низкая в созвучии 0 0 0 0 0 0 1 1 1 1 1 1 *
Решение
Значимость 2,5 0,5 3,5 0,5 1,5 0,5 2 0 3 2 1 0 0
ления начального значения p. соответствующих композиций в базе разрабатываемой системы.
Рассмотренные выше правила вычисления значимости нот в форме инструкций «если - то» представляют собой базу знаний, являющуюся ключевым элементом инженерии знаний. В нашем случае база знаний может быть представлена таблицей.
В строках таблицы перечислены факторы. Содержимое ячейки показывает, активен ли фактор. Символ * используется, чтобы показать, что данный фактор не имеет значения. В столбцах перечислены ситуации (все возможные комбинации факторов). Таким образом, значимость ноты может быть вычислена с использованием формулы z* = CjV. + c2r* + c3m*, представленной в подразделе «Интегральная оценка сходства образцов, используемая алгоритмом EMD3D», при этом значения переменных вычисляются по правилам, изложенным выше.
В дальнейшем данная база может расширяться с учетом выявления новых знаний. Использование баз знаний позволяет компенсировать недостатки алгоритмов формального сопоставления музыкальных фрагментов, не позволяющих учесть некоторые особенности человеческого восприятия.
С точки зрения пользователя поисковая система представлена интерфейсом, обеспечивающим доступ к возможностям системы. Среди ключевых
списокл
1. Hatch, W. A quick review of audio fingerprinting: Technical report [Электронный ресурс] / W. Hatch. -McGill University. -2003. -Режим доступа: http://www. music.mcgill.ca/~wes/docs/finger2.pdf
2. Typke, R. A survey of music information retrieval systems [Текст] / R. Typke, F. Wiering, R. C. Veltkamp // In Proc. of the 6th International Conf. on Music Information Retrieval (ISMIR). -2005. -№ 1020.
функций предлагается реализовать поиск по одному или нескольким параметрам: музыкальным инструментам, музыкальному размеру, тональности, названию, автору, монофоническому или полифоническому образцу. При сравнении по образцу можно использовать накопленную статистическую информацию, позволяющую выделить из композиции действительно важные ноты. Статистически значимые ноты можно в дальнейшем использовать для индексирования базы шаблонов. Например, в [9] для задач поиска в полифонических фрагментах указывается на сложности, связанные именно с количеством обрабатываемой информации. В качестве решения предлагается удалять ноты, не имеющие отношения к мелодии, на основе некоторого формального алгоритма. Наше предложение сводится к тому, чтобы удалять ноты на основе их статистической значимости.
Рассматривая жизненный цикл поисковой системы, можно предположить, что алгоритм, используемый для сравнения, является переменной величиной [10]. При этом накопленная база знаний может использоваться для улучшения свойств любого выбранного алгоритма (а не только EMD). Поскольку в настоящий момент, похоже, не существует алгоритмов, работающих во всех ситуациях в близкой к человеку манере, одним из перспективных направлений является разработка и применение баз знаний, позволяющих учесть разнообразные (и часто противоречивые) аспекты человеческого восприятия.
гературы
3. Isikhan, C. A survey of melody extraction techniques for music information retrieval [Электронный ресурс] / C. Isikhan, G. Ozcan // In Proc. of 4th Conf. on Interdisciplinary Musicology (SIM'08). -2008. -Режим доступа: http://cim08.web.auth.gr
4. Shasha, D. High Performance Discovery in Time Series: Techniques and Case Studies [Text] / D. Shasha, Y. Zhu. -Springer Verlag, NY, 2004.
5. Ukkonen, E. Sweepline the Music! Lecture Notes in Computer Science [Text] / E. Ukkonen, K. Lemstrom, V. Makinen // Comp. Sci. in Perspective (Ottmann Festschrift); Ed. R. Klein [et al.]. -2003. -P. 330-342.
6. Typke, R. Using transportation distances for measuring melodic similarity [Электронный ресурс] / R. Typke [et al.] // In Proc. of the International Conf. on Music Information Retrieval (ISMIR). -2003. -Режим доступа: http://ismir2003.ismir.net
7. Madsen, S.T. A complexity-based approach to melody track identification in midi files [Электронный ресурс] / S.T. Madsen, G. Widmer // In Proc. of the International Workshop on Artificial Intelligence and Music (MUSIC-AI 2007) held in conjunction with the 20th International Joint Conf. on Artificial Intelligence
(IJCAI 2007). -2007. -Режим доступа: http://www.ofai. at/~soren.madsen/pub/music-ai07.pdf
8. Uitdenbogerd, A.I. Manipulation of music for melody matching [Text] / A. L. Uitdenbogerd, J. Zobel // In Proc. of the 6th ACM international Conf. on Multimedia. -ACM NY, 1998. -P. 235-240.
9. Madsen, S.T. Automatic reduction of midi files preserving relevant musical content [Text] / S.T. Madsen, R. Typke, G. Widmer // In Proc. of the 6th International Workshop on Adaptive Multimedia Retrieval (AMR'08). -Springer-Verlag. -2008. -P. 89-99.
10. Kuznetsov, A. Searching for Music: From Melodies in Mind to the Resources on the Web [Text] / A. Kuznetsov, E. Pyshkin // In Proc. of the 13th International Conf. on Humans and Computers (HC-2010), University of Aizu Press, 2010. -P. 152-158.
УДК 004.415
В.П. Котляров
критерии покрытия требований в тестовых сценариях, сгенерированных из поведенческих моделей приложений
Ключевая проблема современного тестирования - проверка соответствия семантики реализованного программного продукта семантике, заданной заказчиком в требованиях. Суть проблемы в том, что набор тестов, проверяющий выполнение требований, не гарантирует проверку их семантики. В статье, в отличие от традиционных критериев [9], предложен критерий, позволяющий согласовать с заказчиком и проверить при тестировании семантику требований.
Формализация требований
В современной проектной документации формулировка требований задается либо конструктивно, когда из текста требования на естественном языке удается реконструировать процедуру контроля или сценарий проверки выполнения данного требования, либо неконструктивно, когда заданное в требовании свойство не содержит пояснения способа его проверки.
Поведенческие требования при наличии заданного сценария проверки являются конструктивно заданными и допускают для проверки реализуемости использование верификации или
тестирования. Неповеденческие требования часто задаются неконструктивно, что заставляет в процессе формализации привлекать дополнительную информацию, позволяющую реконструировать сценарий их проверки, т. е. привести неконструктивную форму задания требования к конструктивной.
Процедура или сценарий проверки некоторого требования заключается в задании перечислимого упорядоченного набора событий, фиксация которого в процессе исполнения приложения будет для заказчика критерием выполнимости соответствующего требования. Подобную последовательность событий в дальнейшем изложении будем называть критериальной последовательностью или цепочкой [1]. Каждому требованию может быть сопоставлена одна или несколько критериальных цепочек. Отслеживая в поведенческом сценарии системы факт выполнения критериальной цепочки, можно утверждать, что соответствующее требование в анализируемой системе удовлетворено.
Специальная структура данных (Traceability Matrix) на рис. 1 проектирует исходные требова-
