close

Вход

Забыли?

вход по аккаунту

?

bur

код для вставкиСкачать
Федеральное агенТство по образованию
Государственное образовательное учреждение
высшего профессионального образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
В. В. Бураков
УПРАВЛЕНИЕ КАЧЕСТВОМ
ПРОГРАММНЫХ СРЕДСТВ
Монография
Санкт-Петербург
2009
УДК 004.3
ББК 32.81
Б91
Рецензенты:
заместитель генерального конструктора «СКБ Орион»,
доктор технических наук, профессор М. Ю. Охтилев;
заместитель директора СПИИРАН по научной работе,
Заслуженный деятель науки РФ, доктор технических наук,
профессор Б. В. Соколов
Утверждено
редакционно-издательским советом университета
в качестве монографии
Бураков В. В.
Б91 Управление качеством программных средств: монография / В. В. Бураков. – СПб.: ГУАП, 2009. – 288 с.: ил.
ISBN 978-5-8088-0437-1
Издание посвящено описанию методологии, объединяющей
несколько формальных моделей и алгоритмов, которые в комплексе позволяют оценивать и улучшать качество программ
предсказуемым и управляемым способом. Представленные модели и алгоритмы обеспечивают необходимую формальную основу
для создания систем, направленных на автоматизацию процессов
управления качеством программ: разработку модели качества
и измерений, нахождение низкокачественных компонент, выработку мероприятий по улучшению качества, отслеживание и
оперативное реагирование на выходы показателей качества за допустимые пределы.
Монография предназначена для студентов старших курсов и
аспирантов технических направлений обучения, а также для специалистов, занимающихся разработкой программного обеспечения.
УДК 004.3
ББК 32.81
ISBN 978-5-8088-0437-1
© ГУАП, 2009
© В. В. Бураков, 2009
ВВЕДЕНИЕ
В отличие от технологических процессов производственных
предприятий, подлежащих хорошо определенному, часто стандартизованному контролю, в области разработки программных
средств (ПС) не удается в точности применить те же принципы
управления качеством. Этому способствует принципиальное
отличие в характере производства товаров и разработки ПС.
В первом случае существует повторяемая, детерминированная
последовательность действий, в то время как разработка ПС носит наукоемкий, экспериментальный характер. Несмотря на существование подходов к инженерии разработки ПС, эта область
все еще является «молодой» и соответствующим методологиям
не хватает «зрелости».
Область управления качеством ПС развивается уже на протяжении четырех десятилетий, однако говорить о повсеместном
повышении качества ПС не приходится. Основная причина этого
заключается в том, что существующие модели оценки качества
не выполняют своей главной задачи: предоставить количественную информацию, необходимую для принятия управленческих
и инженерных решений на протяжении всего жизненного цикла
(ЖЦ) ПС. Неопределенности и пробелы в формализации характеристик ПС оставляют широкое поле для произвола при оценивании их качества, ведут к появлению дефектов и ошибок при
применении ПС пользователями. Возрастание сложности и ответственности задач, решаемых ПС, а также возможного ущерба
от недостаточного их качества обуславливают важность решения проблемы точного описания требований к характеристикам
качества и их измерениям на различных этапах ЖЦ ПС. В ряде
стандартов и публикаций большое внимание уделяется процессам обеспечения качества ПС, однако в основном умалчивается,
что означает высокое качество, какими характеристиками оно
описывается, как его следует измерять и сравнивать с требованиями, формализованными в техническом задании (ТЗ) [1].
По разным оценкам, при создании ПС стадия разработки
занимает 10–15 % бюджета, при этом до 80 % может быть потрачено на исправления ошибок, возникших на этой стадии [2].
Согласно данным отчета, опубликованного в 2002 г. Национальным институтом по стандартам и технологии, объем экономических потерь из-за ошибочного программного обеспечения в США
достигает миллиардов долларов в год и составляет, по некоторым
3
оценкам, около 1 % национального валового внутреннего продукта [3]. Подобных данных о ситуации с разработкой ПС в РФ
нам найти не удалось, но, скорее всего, тенденция не противоречит той, которую можно увидеть согласно данным о разработке
ПС в США.
В работе [4] дано следующее определение качественного проекта ПС: «Хороший проект является результатом баланса компромиссов с целью минимизации общей стоимости разработки
системы»; в работе [5] отмечается, что высококачественный проект по разработке ПС должен иметь атрибуты, которые обуславливают качество конечного продукта: корректную реализацию
функциональных требований, простоту понимания, реализации,
тестирования и модификации. Довольно непросто отличить хороший проект от плохого, поэтому следует анализировать влияния, которые оказывает использование тех или иных проектных
решений на разрабатываемое ПС. Цель управления качеством
ПС состоит не столько в стремлении разработать самую совершенную программу, сколько в выявлении проектных решений,
которые могут привести к плохому дизайну. Невозможно окончательно зафиксировать набор правил, выполнение которых обуславливает разработку высококачественной программы. Однако
может быть выявлен набор критериев, принципов разработки,
выполнение которых может повысить качество. Например, в
случае объектно-ориентированной разработки такими принципами являются управляемая сложность, правильная абстракция
данных, уменьшение сцепления, увеличение связности и многие
другие.
При измерении качества ПС само понятие качества декомпозируется на измеримые части [6]. Эти части являются упрощенной проекцией качества, его моделью. Сложно говорить о
систематизации измерений свойств ПС без построения соответствующей модели качества. С точки зрения заказчика, модель
качества помогает создать нужную спецификацию. В этом случае при отсутствии модели сложно четко определить, что заказчик вкладывает в понятие «качество». Хорошая модель качества
является измеримой и позволяет определять и соотносить качество ПС с точки зрения всех основных сторон, участвующих в
разработке: пользователей, разработчиков и заказчиков. Модель
качества должна опираться на соответствующую модель измерений, что позволит количественно оценить состояние ПС с точки
4
зрения качества. Построение обобщенных, не адаптируемых моделей качества и измерений, применимых для любого рода ПС,
представляется нереальной задачей. Показатели и метрики качества во многом зависят от типа и предметной области ПС. Проанализировать все составляющие качества сразу представляется
сложным. Обычно это работа экспертов, которая состоит в поиске
компромиссов между функциональной полнотой, высоким качеством, минимальными затратами и кратчайшими сроками разработки. При разработке модели явно или не явно проводят ряд
итераций, на каждой из которых понятие качества детализируется в виде набора показателей. Таким образом от абстрактного
понятия «качество» приходят к детальному набору показателей,
которые можно измерять. Ни одна из существующих моделей
в явном виде не задает этот итеративный процесс детализации,
поэтому деятельность по разработке показателей качества носит
сугубо экспертный характер.
Метрики находят свое применение во многих процессах разработки ПС: расчет затрат на разработку, управление проектом
разработки, оценка качества ПС, оценка соответствия требованиям ТЗ, определение завершенности итераций (например, готовности к тестированию), оценка степени готовности ПС к отчуждению, оценка рисков, планирование итераций. При наличии
модели качества можно ранжировать компоненты ПС, выявлять
риски и усиливать вложения ресурсов в наиболее критичные с
точки зрения качества компоненты – т. е. управлять процессом
разработки [7]. Перспективными областями использования метрик и моделей качества являются системное прогнозирование
разработки ПС, ранняя идентификация компонентов, разработка которых имеет высокий риск, определение принципов проектирования. Несмотря на большой и продолжающий возрастать
интерес к использованию метрик в области инженерии ПС, все
методологии и технологии использования метрик до сих пор
являются частными, узкими, направленными на решение конкретных задач. Измерения выступают в качестве основного аналитического средства для лучшего понимания и контроля процессов разработки и самой ПС. Тем не менее в настоящий момент
отсутствует согласованный, однозначно воспринимаемый набор
метрик для любой парадигмы.
В области управления качеством ПС к настоящему моменту
было разработано огромное количество метрик и несколько де5
сятков моделей качества. Существует возможность, поддерживаемая средствами разработки ПС, измерять различные аспекты
дизайна программ. Проблема в использовании этих метрик заключается в их несогласованности, также очевиден семантический разрыв между измерениями и их интерпретацией, разрыв
между количественным и качественным уровнями оценки. Разные значения метрик ПС сами по себе смысла не имеют, смысл
приобретается благодаря их интерпретации, которая реализуется в модели качества. Оценивание качества ПС может быть возложена на группу экспертов, однако в случае больших систем
это малореалистично, необходимо наличие автоматизированного средства оценки качества, не взамен, а в качестве поддержки
опыта и интуиции эксперта. Разработка такого средства требует
формализации модели качества и измерений, а также методов
классификации качественного состояния ПС по наборам значений метрик.
Другим недостатком существующих моделей качества является трудность инженерной интерпретации значений показателей,
которые эти модели вводят [8]. Реализация этой интерпретации
возможна только за счет учета принципов проектирования или
архитектурных решений, которые соотнесены с тем или иным
способом реализации проекта, использованием определенных
языков программирования и т. п. Существующие модели качества не регламентируют четкое соотнесение показателей качества и практик проектирования в рамках определенной парадигмы, а именно принципы проектирования устанавливают для
каждой парадигмы границы качества [9].
Существующие модели качества не определяют аспекты использования результатов оценки [10]. Основными задачами
управления качеством ПС являются идентификация типов дефектов, их локализация и выполнение мероприятий по их исправлению. По распространенным в настоящий момент моделям
качества может быть получена информация о типах и локализации дефектов (за счет определения допустимых интервалов значений метрик), при этом данные о возможных мероприятиях по
устранению дефектов получить затруднительно. Отсутствуют
формальные способы связывания моделей качества с методами
улучшения кода. Недопустимые значения метрик – лишь симптомы плохого кода, мероприятия по исправлению дефектов на
базе наличия только этих данных сформировать не удастся. Ин6
формация о наличии отклонений значений метрик от эталонных
должна быть правильно интерпретирована, сами по себе эти данные, скорее, запутают, чем помогут отыскать нужные преобразования кода. Инженер, занимающийся разработкой качественной
ПС, мыслит в терминах хорошего дизайна, а не в недопустимых
значениях метрик. Задача подбора мероприятий по улучшению
кода является многокритериальной и требует для своего решения привлечения соответствующего аппарата.
В качестве обобщения сформулируем основные существующие проблемы в области управления качеством ПС:
1) отсутствие адаптируемых моделей качества, задающих недвусмысленное толкование характеристик качества и однозначную интерпретацию измерений, проблемы низкой информативности моделей качества, сложности инженерной интерпретации
результатов оценки качества, отсутствие связи модели качества
с принципами проектирования;
2) отсутствие модели измерений ПС, низкий уровень согласованности определений метрик;
3) отсутствие алгоритма оценки качества ПС, формально задающего этапы оценки;
4) отсутствие информации о связи между программными дефектами и мероприятиями по их устранению;
5) отсутствие алгоритма управления качеством ПС, формально описывающего основные процессы оценки и улучшения качества ПС.
Представляемая монография содержит описания результатов
научной работы, посвященной исследованию процессов обеспечения качества и созданию технологии контроля и повышения
качества программных средств. Достижение этих целей было
связано с выполнением следующих этапов исследования:
1) создание модели ПС, служащей основой для описания и измерения характеристик ПС, квантификации принципов проектирования и спецификации преобразований ПС, описывающей
ПС в не зависимом от предметной области, типа и парадигмы разработки виде, содержащей механизмы для адаптации с учетом
предметной области, типа ПС и парадигмы;
2) создание формальной модели качества ПС, которая содержит механизмы для формального определения характеристик
качества и их отношений, предоставляет средства для учета
принципов проектирования;
7
3) создание модели измерений ПС, содержащей механизмы
для формального определения метрик и их отношений, соответствующей по своей структуре модели качества ПС, имеющей
механизмы для квантификации принципов проектирования, содержащей информацию о преобразованиях ПС;
4) разработка алгоритма оценки качества ПС, формально описывающего процесс оценки качества и регламентирующего использование моделей качества и измерений ПС;
5) создание модели преобразований ПС, основанной на модели
ПС и определяющей инструментарий для формального определения преобразований ПС;
6) разработка алгоритма преобразований, формально задающего порядок реализации преобразований ПС, которые описываются моделью преобразований ПС;
7) разработка алгоритма управления качеством ПС, формально описывающего процесс управления качеством ПС на основе
моделей ПС, качества ПС, измерений ПС, преобразований ПС,
содержащего механизмы для адаптации с учетом изменения модели качества ПС;
8) программная реализация созданных моделей и алгоритмов
и опытная эксплуатация созданных ПС.
Монография структурирована в соответствии с приведенными этапами исследования.
Первая глава посвящена описанию модели программных
средств. В качестве основы для формирования модели выбрана
теория графов. Описаны свойства модели, подходы к формализации принципов проектирования программ.
Вторая глава посвящена описанию модели качества программных средств. Анализируются существующие модели качества, формулируются требования к вновь создаваемой модели,
приводится формальное описание модели и ее свойств.
Третья глава посвящена оценке качества программных
средств. Описаны два элемента разработанной теории оценки
качества программ – модель измерений и алгоритм оценки программных средств. Приводится анализ существующих стандартов в области оценки качества, разработана модель измерений,
алгоритм оценки качества, описывающий процесс использования модели измерений.
В четвертой главе представлено описание подхода к улучшению программных средств. Глава состоит из двух подразделов,
8
в первом на основе теории переписывания графов описывается
модель, во втором – алгоритм преобразований программных
средств.
Пятая глава посвящена описанию алгоритма управления
качеством программных средств. Алгоритм использует модели,
описанные в предыдущих главах.
В шестой главе описаны результаты практического апробирования теории управления качеством программных средств.
Приведена информация о шести программных проектах, в результате реализации которых были созданы средства для управления качеством программ. Описываются результаты опытной
эксплуатации этих средств.
Издание будет полезно студентам старших курсов и аспирантам, занимающимся изучением проблем инжиниринга программ
и применения формальных методов для разработки программного обеспечения, а также специалистам в области ПО.
9
Глава 1. Моделирование
программных средств
Объектом системы управления качеством является программное средство, в целях формального описания которого должна
быть создана модель. Для представления программных сущностей и их взаимоотношений целесообразно использованы графы.
В силу своей математической природы теория графов является
одним из самых простых и удобных формализмов для представления программ, их структур и поведения. Наглядность и простота представления программных сущностей и взаимоотношений
между ними сочетается в графовых спецификациях с развитым
математическим базисом. Одним из первых шагов в этой области
следует считать [11], где графы использовались для спецификации сообщений, которые объекты посылают друг другу во время исполнения программы, что давало возможность улучшения
понимания, фиксации свойств и отладки программ на Smalltalk.
Другие разновидности графов использовались в работе [12] для
описания поведения крупных объектно-ориентированных систем. Помимо графов вызовов методов, использовались графы
вызова объектов, графы наследования и агрегации. Каждый из
типов графов описывал отдельную проекцию поведения программы, что повлекло за собой улучшение понимания поведения программы, которое сказалось на увеличении повторного использования кода. В работе [13] концептуальные графовые нотации
использовались для описания объектно-ориентированных концепций. Некоторые подходы к формальному описанию метрик
также базируются на описании программных систем с помощью
теории графов [14].
Основными отличиями разработанной графовой модели от
перечисленных аналогов являются:
– возможность моделирования программного средства с той
степенью детализации, которая необходима для решения задачи
управления качеством, возможность варьирования этой степени;
– введение ролей программных сущностей для учета качества
архитектурных решений;
– проработка модели с точки зрения остальных компонентов
системы управления качеством – модели измерений, служащей
для оценивания качества, и модели преобразования ПС, предназначенной для улучшения качества.
10
1.1. Графовая модель программы
Определение 1. Ориентированный граф G = (V,E,s,t) состоит
из двух множеств, конечного множества V, элементы которого
называются вершинами, и конечного множества E, элементы
которого называются ребрами. Каждое ребро связано с упорядоченной парой вершин. Для обозначения вершин используются
символы v1,v2,v3… а для обозначения ребер – символы e1,e2,e3…
Если e1 = (vi,vj), то vi и vj называются оконечными вершинами
e1, при этом vi – начальная вершина, a vj – конечная вершина e1.
Все ребра, имеющие одну пару начальных и конечных вершин,
называются параллельными. Дуга называется петлей, если инцидентная вершина vi является одновременно начальной и конечной ее вершиной.
Функции s: E→ V и t: E→ V связывают с каждым ребром в точности одну начальную и одну конечную вершины.
Определение 2. Мультиграф. Граф является мультиграфом в
том случае, если для разных ребер допускается совпадение как
начальных, так и конечных вершин.
Графы, удовлетворяющие вышеприведенным определениям,
формируют объекты в категории. При этом морфизмами являются функции, которые возвращают начальные и конечные вершины для всех ребер. Доказательство этого свойства можно найти в [15].
Определение 3. Категория графов. Для двух графов G и H графовый морфизм f: G→ H представляет собой пару (fv: VG→ VH, fe:
EG → EH), такую, что выполняется fv ° sG = sH ° fe и fv°tG = tH ° fe.
Категория графов, содержащая в качестве объектов графы, а в качестве морфизмов – графовые гомоморфизмы, будет обозначаться Graph.
Функции fv и fe называются функциями отображения соответственно вершин и ребер. Придание этим функций свойства биективности упрощает описание свойства изоморфизма категории
Graph.
Определение 4. Графовый изоморфизм. Графовый изоморфизм f: G → H представляет собой графовый гомоморфизм, в
котором функции fv и fe являются биективными. В этом случае
говорят, что G изоморфен H.
Изоморфизм графов представляет собой не что иное, как гомоморфизм, являющийся одновременно инъективным и сюръективным.
11
Определение 5. Инъективные и сюръективные графовые
морфизмы. Графовый гомоморфизм f является инъективным
(сюръективным), если fv и fe являются инъективными (сюръективными) функциями. Категории GraphI (GraphS) являются подкатегориями Graph с графами в качестве объектов и инъективными (сюръективными) графовыми гомоморфизмами в качестве
морфизмов.
Не сложно убедиться в том, что GraphI ⊆ Graph и GraphS ⊆
⊆ Graph. Инъективные графовые морфизмы имеют важное свойство, согласно которому никакие две отличающиеся вершины
или ребра не отображаются на одну и ту же вершину или ребро
соответственно. Это свойство можно использовать при описании
подграфа. Граф является подграфом другого графа, если он имеет такую же структуру, т. е. если можно определить такое инъективное отображение вершин и ребер, при котором структура
графа не меняется.
Определение 6. Подграф. H является подграфом G (обозначается H ⊆ G), если существует инъективный графовый морфизм
m: H → G, называемый соответствием H в G.
Как и для функций, графовый морфизм f: G → H является тотальным, если он повсюду определен на G. Иначе морфизм называется частичным, т. е. определенным на одном из подграфов
графа G.
Определение 7. Частичные и тотальные графовые морфизмы. Графовый морфизм f является тотальным, если и только
если функции fv и fe тотальны, в противном случае, графовый
морфизм является частичным.
Определение 8. Входные и выходные ребра. Для графа G и
вершины v ∈ VG существуют:
1) множество входных ребер IEG(v) = {e ∈ EG: t(e) = v};
2) множество выходных ребер OEG(v) = {e ∈ EG: s(e) = v};
3) множество входных вершин IVG(v) = {t(e): e ∈ IEG(v)};
4) множество выходных вершин OVG(v) = {s(e): e ∈ OEG(v)};
5) множество смежных вершин AG(v) = IVG(v) ∪ OVG(v);
6) порядок dG(v) = |IEG(v)| + |OEG(v)|;
7) входное число вершин inG(v) = |IVG(v)|;
8) выходное число вершин outG(v) = |OVG(v)|.
В определении, данном выше, функции inG(v) (outG(v)) возвращают число смежных для вершины v вершин графа G, которые
связаны с v входящими (выходящими) ребрами. Функция dG(v)
12
подсчитывает общее число ребер, в графе G соединенных с вершиной v.
Множества IVG, OVG, AG являются подмножествами декартова произведения VG × VG. Например, IVG ⊆ VG × VG, такое, что две
вершины (v,w) ∈ IVG, если и только если w ∈ IVG(v). Аналогично
определяются OVG и AG.
Лемма 1. Симметричность графа. Для графа G выполняется
OVG = IVG-1.
Определение 9. Зависимости в графе. Для графа G и двух его
вершин v,w∈IVG соблюдаются следующие зависимости:
1) w напрямую зависит от v, если (v,w) ∈ IVG;
2)  "n Î  : w n-арно зависит от v, если (v,w) ∈ (IVG )n;
3) w транзитивно зависит от v, если (v,w) ∈ (IVG )+; (IVG )+ называется отношением с транзитивной зависимостью;
4)  "n Î  : innG (v) = IVGn (v) ;
5)  "n Î  : outnG (v) = OVGn (v) ;
+
6)  "n Î  : in+
G (v) = IVG (v) ;
+
7)  "n Î  : out+
G (v) = OVG (v) .
Говорят, что w напрямую связана с v, если существует ребро, имеющее w в качестве начальной и v в качестве конечной
вершины. Если w зависит от v не напрямую, а через n-реберпосредников, то это называется зависимостью n-го порядка w от
v. При этом величины innG и outnG будут отражать n-й порядок
влияния, которое оказывает v на w в рамках возможных изменений вершины w [16].
Определение 10. Граф, индуцированный посредством отношения. Пусть R ⊆ V × V – отношение на множестве вершин V.
Говорят, что граф G=(V,E,s,t) индуцируется посредством R, если
существует биективная функция f:R → E:(v,w) → e, такая, что
∀(v,w)∈R:s(f(v,w))=v; t(f(v,w))=w.
Согласно определению отношения, индуцированный граф не
является мультиграфом.
Определение 11. Замыкание n-го порядка и транзитивное замыкание графа. Для графа G, "n Î , замыкание n-го порядка
Gn является графом, индуцированным посредством (OVG)n. Транзитивное замыкание G+ является графом, индуцированным посредством (OVG)+.
13
1.1.1. Расширение базовой теории графов
В качестве расширений к базовой структуре графа, описанного выше, используются метки, роли и типы. Типизация является
классификацией вершин и ребер и используется с целью упрощения структуры графа, метки служат для именования вершин
и ребер, а роли вводятся для спецификации контекста использования моделируемой программной сущности.
1.1.2. Понятие помеченного графа
Определение 12. Помеченный граф. Пусть L=(VL,EL),
A=(VA) – пара непересекающихся потенциально бесконечных
множеств меток и ролей соответственно. (L,A)-помеченный граф
G представляет собой тройку (g,l,a), такую, что имеет место:
1) g=(V,E,s,t) – граф;
2) l=(vl:V→VL, el:E→EL) – пара функций пометки соответственно вершин и ребер, при этом vl является инъективной;
3) a=(va:V→VA) – функция отображения вершин на множество ролей.
Помеченные графы успешно применяются для формализации
ПС [17]. В описываемом подходе вводятся требования уникальности каждой пары «метка – тип вершины» и каждой «метка –
тип ребра», таким образом, метка и тип вершины или ребра выступают в качестве структурного уникального идентификатора.
Помимо этого, допустимо сопоставить с ребром пустую метку ε.
В силу того, что V∩E=∅, на множества меток для вершин и ребер
не налагается требований отсутствия пересечений.
Метки служат для идентификации вершин и ребер. Роли
описывают контекст использования сущности. Хорошим примером использования ролей являются описания шаблонов
проектирования [18, 19]. Обычно шаблоны описываются с помощью фрагмента сущностей и их связей, при этом каждая из
сущностей играет в рамках структуры связей определенную
роль. На сущность не накладывается ограничений по уникальности выполняемой роли. С точки зрения разных проектных
решений, одна и та же сущность может быть задействована
в разных ролях.
Целесообразно описывать шаблоны с помощью графов, которые являются прототипами фрагментов реальной графовой модели ПС.
Так же, как и в случае с категорией Graph, (L,A)-помеченные
графы образуют категорию, для определения которой понадобят14
ся определения частичных морфизмов, с аксиомами в областях
определений, соответствующие dom(fv) и dom(fe).
Определение 13. Морфизмы, сохраняющие структуру. Для
(L,A)-помеченных графов G и H, f:G→H является помеченным
графовым морфизмом, если (fv : VG ® VH , fe : EG ® EH ) является
частичным графовым морфизмом между G и H.
L-сохраняющим помеченным графовым морфизмом f:G→H
называется такой помеченный графовый морфизм, для которого
выполняется:
1)  "v Î dom(fv ) : vlG = vlH  fv ;
2)  "e Î dom(fe ) : elG = elH  fe .
A-сохраняющим помеченным графовым морфизмом f:G→H
называется такой помеченный графовый морфизм, для которого
выполняется:
1)  "v Î dom(fv ) : vaG = vaH  fv ;
2)  "e Î dom(fe ) : eaG = eaH  fe .
(L,A)-сохраняющим помеченным графовым морфизмом является морфизм, одновременно A-сохраняющий и L-сохраняющий.
С помощью данных четырех графовых морфизмов можно
определить четыре различных категории, объекты которых являются (L,A)-помеченными графами. При именовании каждой
из этих категорий префикс используется для обозначения объектов (например, префикс L используется для помеченных графов),
а суффикс используется для обозначения морфизма, т. е. вида
сохраняемой структуры (например, суффикс LA, если и метки,
и роли сохраняются). Каждая из категорий параметризируется
множеством меток L и множеством ролей A.
Определение 14. Категории помеченных графов. LGraph(L,A) –
категория с (L,A)-помеченными графами в качестве объектов
и помеченных графовых морфизмов в качестве морфизмов.
LGraph(L,A) – категория с (L,A)-помеченными графами в качестве объектов и L-сохраняющих помеченных графовых морфизмов в качестве морфизмов. LGraphA(L,A) – категория с (L,A)помеченными графами в качестве объектов и A-сохраняющих
помеченных графовых морфизмов в качестве морфизмов.
LGraphLA(L,A) – категория с (L,A)-помеченными графами в качестве объектов и (L,A)-сохраняющих помеченных графовых морфизмов в качестве морфизмов. Имеют место следующие свойства:
LGraphLA(L,A) ⊆ LGraphL(L,A) ⊆ LGraph(L,A); LGraphLA(L,A) ⊆
LGraphA(L,A) ⊆ LGraph(L,A).
15
В случае однозначности контекста обозначения (L,A) в префиксе наименования категории будут опускаться. Нетрудно убедиться, что LGraph, LGraphL, LGraphA, LGraphLA формируют
категории и являются подкатегориями друг друга. По определению 12, графовые морфизмы всегда инъективны. Это свойство
поможет упростить некоторые дальнейшие утверждения и доказательства.
Лемма 2. Инъективность графовых морфизмов. Если f:G → H
является LGraphL-морфизмом, то f является инъективной функцией.
Доказательство
fv:VG→VH является инъективной в силу того, что для ∀v,w ∈
∈ dom(fv) из v≠w следует vlG(v)≠vlG(w), так как vl является
инъективной. Из этого следует, что по определению LGraphLморфизма vlH(fv(v))≠vlH(fv(w)). В итоге, в силу различающихся
меток, fv(v)≠fv(w).
fe:EG→EH является инъективной, так как для ∀e,g ∈ dom(fe)
из e ≠ g следует elG(e)≠elG(g), sG(e)≠sG(g) и tG(e)≠tG(g). Следовательно, по определению LGraphL-морфизма fe(e)≠fe(g).
1.1.3. Понятие помеченного типизированного графа
Добавление к формализму помеченного графа механизма, связывающего с каждым ребром и вершиной понятие типа, служит
целям классификации. Последняя позволяет выявить сходные
свойства вершин или ребер, тем самым упрощая представление
графа.
Определение 15. Помеченный типизированный граф. Пусть
T=(VT,ET) – пара непересекающихся конечных множеств
предопределенных типов вершин и ребер. (L,A)-помеченный
T-типизированный граф G является двойкой (g,type), такой, что g
является (L,A)-помеченный графом, а type=(vt:V→VT,et:E→ET) –
пара функций, vt связывает с каждой вершиной из V ее тип VT, а
et – с каждом ребром из E его тип ET.
Определение 16. Морфизмы, сохраняющие типы вершин и ребер. Пусть G и H – (L,A)-помеченные T-типизированные графы.
f:G→H представляет собой помеченный типизированный графовый морфизм, если f является помеченным графовым морфизмом между (L,A)-помеченными графами G и H. T-сохраняющий
помеченный графовый морфизм f:G→H – это такой помеченный
типизированный графовый морфизм, для которого выполняется:
16
1)  "v Î dom(fv ) : vtG = vtH  fv ;
2)  "e Î dom(fe ) : etG = etH  fe .
Определение 17. Категория помеченных типизированных
графов. Категория LTGraph(L,A,T) содержит (L,A)-помеченные
T-типизированные графы в качестве объектов и графовые морфизмы в качестве морфизмов. LTGraphL(L,A,T) содержит
L-сохраняющие помеченные графовые морфизмы в качестве морфизмов. LTGraphA(L,A,T) содержит A-сохраняющие помеченные
графовые морфизмы в качестве морфизмов. LTGraphT(L,A,T)
содержит T-сохраняющие помеченные графовые морфизмы в
качестве морфизмов. Соответственно, определяются категории
LTGraphLA(L,A,T), LTGraphLT(L,A,T), LTGraphAT(L,A,T) и
LTGraphLAT(L,A,T). По аналогии с определением 14, можно показать, что каждая из этих категорий является подкатегорией
другой.
1.1.4. Визуализация помеченных типизированных графов
При визуализации вершины и ребра графа представляются
прямоугольниками, разделенными на секции. Для отображения
вершин отводятся три секции, в первую помещается тип вершины, во вторую – метка, в третью – перечень ролей, разделенный
запятыми. Для отображения ребер отводятся две секции, в первую помещается тип вершины, во вторую – метка. Ребра обозначаются сплошными линиями со стрелками на конце в силу того,
W
BCTUSBDU$MBTT
B
TVCKFDU
F
M
C
PCTFSWFS
F
HFOFSBM
O
W
W
DMBTT
D
DPODSFUF4VCKFDU
BCTUSBDU$MBTT
BTTPD
F
HFOFSBM
F
W
F
DMBTT
E
DPODSFUF0CTFSWFS
BTTPD
N
Рис. 1. Пример помеченного типизированного графа
17
что граф является ориентированным. Прямоугольник со спецификацией ребра соединяется с ребром пунктирной линией. В случае отсутствия информации о ролях вершины допускается отображать прямоугольниками с двумя секциями с типом и меткой.
Допускается не приводить информацию о метке ребра, тогда ребро может быть представлено без соответствующего прямоугольника, информация о типе приводится рядом с ребром.
На рис. 1 приведен пример помеченного типизированного графа, отображающего структуру шаблона «наблюдатель».
1.1.5. Абстрактный помеченный граф
В некоторых случаях при работе с графом интерес представляют только метки вершин и ребер, а внутренняя структура
значения не имеет. Математически это выражается посредством
изоморфных помеченных графов. Два (L,A)-помеченных типизированных графа G и H являются изоморфными, если между
ними существует изоморфизм, т. е. G и H имеют тождественную
внутреннюю структуру, являются одинаковыми с точностью до
переименования вершин и ребер. Класс изоморфных графов принято называть абстрактным графом.
Условия изоморфизма графов зависят от используемой категории. При использовании категории LTGraphL(L,A,T) необходимо, чтобы у двух изоморфных графов были одинаковые метки,
для LTGraphLT(L,A,T) и метки, и типы должны быть одинаковыми, а для LTGraphLAT(L,A,T) метки, типы и роли должны совпадать.
BCTUSBDU$MBTT
B
TVCKFDU
BCTUSBDU$MBTT
C
PCTFSWFS
BTTPD
F
HFOFSBM
F
M
HFOFSBM
O
DMBTT
DMBTT
D
DPODSFUF4VCKFDU
E
DPODSFUF0CTFSWFS
BTTPD
N
Рис. 2. Пример абстрактного помеченного типизированного графа
18
При работе с абстрактными помеченными графами используются следующие обозначения. Если v,w∈VG и ε∈EG имеют l(v)=n,
type(v)=ω, l(w)=m, e(ε)=(a,v,w), type(ε)=τ, обозначение (a,n,m)∈G
или (a,n,m,τ)∈G используется для описания ε∈EG. С использованием инъективного ограничения n∈G или (n,ω)∈G обозначает
v∈VG. На рис. 2 приведен пример абстрактного графа.
1.1.6. Понятие подграфа
Для того чтобы определить, является ли помеченный граф H
подграфом графа G, необходимо найти сохраняющий по меткам
и типам графовый морфизм f:H→G.
Существует особый тип подграфа, называемый диапазонным
τ-подграфом. В таких подграфах все ребра имеют тип τ, а ребра
других типов скрываются.
Определение 18. Диапазонный подграф. Пусть G является
(L,A)-помеченным T-типизированным графом и τ∈ET. τ(G) называется τ-диапазонным подграфом графа G, если соблюдаются
следующие условия:
1) τ(G) – подграф графа G с сохраняющим по меткам и типам
морфизмом f: τ(G)→G;
2) "e Î Eτ(G) : etτ(G) (e) = τ;
3) функция fv:Vτ(G)(e) биективна;
4) "e Î EG :etG (e) = τ,$g Î Eτ(G) :fe (g) = e.
На рис. 3 приведен пример τ-диапазонного подграфа, в котором все ребра с типом, отличным от типа general, скрыты.
W
BCTUSBDU$MBTT
B
TVCKFDU
F
W
BCTUSBDU$MBTT
C
PCTFSWFS
HFOFSBM
M
F
HFOFSBM
O
W
W
DMBTT
D
DPODSFUF4VCKFDU
DMBTT
E
DPODSFUF0CTFSWFS
Рис. 3. Пример τ-диапазонного подграфа
19
1.1.7. Принципы типизации
Для описания ограничений на допустимые виды отношений
между программными сущностями вводятся два набора метаграфов: типовые и антитиповые. Первый набор описывает допустимые виды отношений между программными сущностями,
второй – запрещенные. Существование инъективного морфизма
из графа, описывающего программные сущности в каждый из
типовых графов, при одновременном отсутствии инъективных
морфизмов в каждый из антитиповых графов обосновывает корректность графовой структуры ПС.
В работах [20–25] вводится категорное описание типовых
графов, которые представляют собой помеченные графы, чьи
метки определяют типы вершин и ребер графов ПС. Помимо этого, обычно типовые графы содержат описания ограничений на
структуры графов, которые наследуются благодаря введению
частичного порядка на типы. Описываемый нами подход отличается от [20–25] отсутствием ограничений, формулируемых с
помощью логики высказываний, вместо этого, наряду с типовыми графами, описывающими канонические структуры, вводятся антитиповые графы, специфицирующие ограничения на допустимые графовые структуры. Типовый и антитиповые графы
являются не чем иным, как метаграфами помеченного типизированного графа.
Определение 19. Типовый (антитиповый) граф. Пусть
T=(VT,ET) – пара непересекающихся конечных множеств типов,
а TT – T-помеченный граф, называемый типовым (антитиповым)
графом. (L,A)-помеченный TT-типизированный граф является
двойкой (G,tt), такой, что G – (L,A)-помеченный граф и tt:G→TT –
тотальный LGraph-морфизм. Помеченный TT-типизированный
графовый морфизм представляет собой графовый морфизм вида
f:G→H между (L,A)-помеченными TT-типизированными графами. TT-сохраняющий помеченный типизированный графовый
морфизм представляет собой помеченный TT-типизированный
графовый морфизм вида f:G→H, такой, что ttH ° f=ttG для
∀x∈dom(f).
В определении 19 метки вершин типового графа TT соответствуют типам вершин в (L,A)-помеченном T-типизированном
графе. Метки ребер типового (антитипового) графа TT соответствуют типам ребер в (L,A)-помеченном T-типизированном графе.
20
B
M
C
MO
[
Рис. 4. Граф на основе регулярного выражения
С целью расширения описательных возможностей типовых
и антитиповых графов используется нотация формы a ¾¾¾
® b,
exp
где a и b принадлежат множеству типов вершин VG, а exp является регулярным выражением на множестве типов ребер EG. Эти
выражения описывают множества графов в форме, представленной на рис. 4, где слова l1…ln принадлежат языку exp. Если a=b
и n=0 (т. е. l1…ln – пустое слово), тогда граф рис. 4 будет состоять
из одной вершины. Граф, содержащий более одного выражения,
определяет множество графов, получаемых всевозможными заменами этих вершин. Для обозначения пути, состоящего из вершин и ребер определенных типов, будет использоваться символ
« * », для обозначения возможного отсутствия ребра определенного типа – символ « ? ».
При визуализации вершины типового (антитипового) графа
представляются прямоугольниками, в которые помещаются метки вершин. Ребра обозначаются сплошными линиями со стрелками на конце в силу того, что граф является ориентированным.
Для указания типа ребра рядом с линией приводится метка.
1.1.8. Частично-упорядоченные графовые типы
С практической точки зрения, важной возможностью является задание между типами вершин или ребер отношений «тип –
подтип». Аналогично объектно-ориентированным концепциям,
такого рода возможность позволит наследовать специфицированные для родительских типов ограничения на связи для всех
соответствующих подтипов. В силу необходимости допущения
множественного, а не только одиночного типов наследования,
при описании отношений «тип – подтип» используется отношение частичного, а не полного порядка.
Определение 20. Частично-упорядоченный типовый граф. Типовый T-помеченный граф TT является (≤V,≤E)-упорядоченным,
если (VT,≤V) и (ET,≤E) представляют собой частичные порядки.
1.1.9. Морфизмы, сохраняющие подтипы
При использовании понятия подтипов, помимо морфизмов, в
точности сохраняющих типы вершин и ребер, необходимо ввести
21
более облегченный вариант – морфизмы, в рамках которых типы
вершин и ребер могут быть заменены на соответствующие подтипы.
Определение 21. Морфизмы, сохраняющие подтипы. Пусть
TT – T-помеченный (≤V,≤E)-упорядоченный типовый граф, а G и
H – два (L,A)-помеченных T-типизированных графа. Помеченный типизированный графовый морфизм f:G→H является сохраняющим подтипы, если выполняется:
1)  "v : v Î dom(fv ) Þ vtH (fv (v)) £V vtG (v);
2)  "e : e Î dom(fe ) Þ etH (fe (e)) £E etG (e).
Определение 22. Морфизмы, сохраняющие супертипы. Пусть
TT – T-помеченный (≤V,≤E)-упорядоченный типовый граф, а G и
H – два (L,A)-помеченных TT-типизированных графа. Помеченный типизированный графовый морфизм f : G ® H является сохраняющим супертипы, если выполняется:
1)  "v : v Î dom(fv ) Þ vtH (fv (v)) ³V vtG (v);
2)  "e : e Î dom(fe ) Þ etH (fe (e)) ³E etG (e).
1.1.10. Спецификация множественности
Спецификация множественности представляет собой описание допустимого количества вершин или ребер определенного
типа (например, ограничение на допустимое количество агрегируемых сущностей в диаграмме классов UML). Для описания множественности вводятся две функции, предназначенные
для задания атрибутов множественности для вершин и ребер,
mV:V→I\[0,0] и mE:E→I\[0,0], где I – множество всех непустых
интервалов над .
1.2. Адаптация графовой модели к предметной области
Для применения графовых моделей к конкретной области
моделирования или языку программирования необходимо выполнить следующую последовательность действий по адаптации:
1) идентифицировать типы вершин и ребер;
2) определить множество типовых графов;
3) построить множество антитиповых графов.
Рассмотрим выполнение шагов по адаптации применительно к диаграммам классов UML и программному коду на языке
Java.
22
1.3. Моделирование диаграмм классов UML
1.3.1. Идентификация типов вершин и ребер
Так как все типы отношений в UML определены как экземпляры подкласса метакласса Relationship, целесообразно рассматривать все эти подклассы (такие как ассоциация или обобщение) в
качестве типов ребер. Все остальные подклассы, являющиеся
прямыми или косвенными потомками метакласса ModelElement,
отображаются на типы вершин. На рис. 5 представлен фрагмент
метамодели UML. Типовый граф содержит следующие вершины
VT={classifier, interface, class, feature, attribute, operation}, имеются следующие отношения частичного порядка: classifier ≤V
≤V class, classifier ≤V interface, feature ≤V attribute и feature ≤V
≤V operation.
Необходимо обратить внимание на отличия типов в частичном
порядке для помеченного типизированного графа от стандартной
метамодели UML:
1) в целях упрощения описания интерфейсы, параметры и
исключения для операций, ограничение доступа для атрибутов,
операций и ассоциаций, а также виды и роли для ассоциаций не
специфицируются;
2) введен тип ребра Instantiation для описания типов атрибутов и значений операций;
3) введен тип ребра Ownership для описания типов атрибутов
и значений операций.
.PEFM&MFNFOU
3FMBUJPOTIJQ
"TTPUJBUJPO
(FOFSBMJ[BUJPO QBSFOU
TQFDJBMJ[BUJPO
DIJME
HFOFSBMJTBUJPO
$MBTT
$MBTTJGJFS
GFBUVSF
PXOFS
*OUFSGBDF
'FBUVSF
"UUSJCVUF
0QFSBUJPO
Рис. 5. Фрагмент метамодели UML
23
1.3.2. Построение множества типовых графов
Следующим шагом является создание типового графа, отражающего ограничения на типы вершин и ребер. Информация об
этих ограничениях извлекается из метамодели UML.
BTTPDJBUJPO
PXOFSTIJQ
DMBTTJGJFS
HFOFSBMJ[BUJPO
GFBUVSF
JOTUBOUJBUJPO
Рис. 6. Типовый граф
для представления диаграмм классов UML
Сравнивая модели на рис. 5 и 6, необходимо сделать ряд замечаний:
– в типовом графе подклассы Relationship представляются ребрами, а не вершинами;
– все ограничения на классификаторы или свойства в типовом
графе автоматически наследуются классами, атрибутами и операциями, являющимися подтипами;
DMBTT
HFOFSBMJ[BUJPO
DMBTT
DMBTT
PXOFSTIJQ
HFOFSBMJ[BUJPO
PXOFSTIJQ
BUUSJCVUF
HFOFSBMJ[BUJPO
DMBTT
Рис. 7. Антитиповые графы для ограничения отношений обобщения
диаграмм классов UML
24
– по сравнению с метамоделью UML типовый граф имеет две
особенности: ассоциация относится непосредственно к классу, а
не классификатору, и не может связывать более двух классификаторов (для обеспечения последнего пришлось бы использовать
гиперграфы).
1.3.3. Построение множества антитиповых графов
Для примера описания ограничений на структуру диаграммы
классов UML рассмотрим отношение обобщения. На рис. 7 представлены антитиповые графы, специфицирующие следующие
ограничения на корректное описание отношения обобщения:
1) нельзя переопределить атрибут суперкласса в потомке;
2) иерархия наследования не может иметь циклов.
1.4. Моделирование объектно-ориентированного кода
На рис. 8 представлен фрагмент метамодели UML версии 1.5,
посвященный описанию методов. С целью создания модели для
преобразований эта метамодель может быть упрощена. Необходимо учесть, что элементы моделирования потока управления,
7BSJBCMF
.FUIPE
7BSJBCMF"DUJPO
1SPDFEVSF
"DUJPO
*OQVU1JO
1SJNJUJWF"DUJPO
0VUQVU1JO
(SPVQ"DUJPO
1JO
Рис. 8. Фрагмент метамодели UML (1.5) для метода
-PDBM7BSJBCMF
.FUIPE
"DUJPO4FRVFODF
"DUJPO
Рис. 9. Упрощенная метамодель Java-метода
25
входы и выходы введены в метамодель UML в основном для моделирования потоков данных и управления, и для описания преобразований не используются. Упрощенная метамодель метода
на Java для использования при описании преобразований приведена на рис. 9.
1.4.1. Идентификация типов вершин и ребер
В целях простоты изложения некоторые специальные синтаксические возможности Java (например, ссылки this, операторы
if, for, модификаторы abstract, public, protected, private, static,
final, внутренние классы, нити) не используются.
Сущности программы (такие как классы, поля, методы, параметры методов) представляются вершинами, чьи метки представляют собой пары из имени и типа сущности. Множество
VG={In,Cl,Ty,Va,Si,Pa,Bo,Ex} всех возможных типов вершин
представлено в табл. 1. Тело метода (Bo-вершина) отделяется
от сигнатуры (Si-вершины) с целью возможности моделировать
позднее связывание, в рамках которого одна и та же сигнатура
может иметь несколько реализаций. Вершины Bo (тело метода) и
Pa (формальные параметры метода) имеют пустое имя.
Отношения между программными сущностями (такие как агрегация, наследование, поиск метода, доступ к переменной и вызов
метода) представляются с помощью ребер. Метка ребра представляет его тип. Множество EG={in,li,si,ge,me,ty,pa,ex,co,dy,fo,ac,up
,ra} всех возможных типов ребер представлено в табл. 2. Для вершин типа m (принадлежность) метки использоваться не будут.
Таблица 1
Вершины графа
Тип
26
Описание
In
Интерфейс
Cl
Ty
Va
Si
Класс
Стандартный тип
Поле
Сигнатура метода
(включая конструкторы и деструкторы)
в таблице поиска
Пример
EJBObject, EJBHome, TimerSession,
TimerSessionHome, SessionBean,
TimedObject
TimerSessionBean
long
context
myCreateTimer, ejbTimeout,
setSessionContext, ejbCreate,
TimerSessionBean, ejbRemove,
ejbActivate, ejbPassivate
Окончание табл. 1
Тип
Pa
Bo
Ex
Описание
Пример
Формальный параметр
Тело метода
intervalDuration, timer, sc
System.out.println(“TimerSessionBean:
ejbTimeout “)
context.getTimerService()
Выражение в теле
метода
Таблица 2
Ребра графа
Тип
Описание
Пример
in:Cl→In
Реализация интерфейса классом
Позднее связывание
Реализация
интерфейсного
метода в классе
TimerSessionBean implements
SessionBean, TimedObject
myCreateTimer(long intervalDuration)
li:Si→Bo
si:Si→Bo
ge:In→In
ge:Cl→Cl
me:Va→Cl
me:Si→In
me:Bo→Cl
ty:Pa→Cl
ty:Pa→Ty
ty:Va→Cl
Метод myCreateTimer интерфейса TimerSession реализуется
методом myCreateTimer класса
TimerSessionBean
Наследование для TimerSession extends EJBObject
интерфейсов
TimerSessionHome extends EJBHome
Наследование для В данном примере отсутствует
классов
Принадлежность Переменная context принадлежит
поля классу
классу TimerSessionBean
Принадлежность Метод myCreateTimer(long
метода интерфей- intervalDuration) принадлежит интерсу
фейсу TimerSession
Принадлежность Метод myCreateTimer(long
метода классу
intervalDuration) принадлежит классу
TimerSessionBean
Классовый тип
Параметр timer метода ejbTimeout
формального паимеет тип Timer
раметра
Стандартный
Параметр intervalDuration имеет тип
тип формального long
параметра
Классовый тип
Переменная���������������������������
context имеет�������������
������������������
тип���������
������������
Sessionполя
Context
27
Окончание табл. 2
Тип
Описание
ty:Va→Ty Стандартный тип
поля
ty:Si→Cl Классовый тип
возвращаемого
значения
ty:Si→Ty Стандартный тип
возвращаемого
значения
pa:Si→Pa Формальный
параметр
pa:Ex→Ex Фактический
параметр
ex:Bo→Ex
co:Ex→Ex
dy:Ex→Si
fo:Ex→Si
ac:Ex→Pa
ac:Ex→Va
up:Ex→Va
ra:Si→Cl
Пример
В данном примере отсутствует
Метод create() возвращает
TimerSession
В данном примере отсутствует
Метод myCreateTimer имеет формальный парамет intervalDuration
Метод timerService.createTimer вызывается с фактическими параметрами
intervalDuration и «created timer»
Выражение в теле TimerService timerService = context.
метода
getTimerService()
Подвыражение
context для context.getTimerService()
Динамический
В данном примере отсутствует
вызов метода
Делегирование ис- Вызов метода myCreateTimer инполнения интертерфейса TimerSession приведет
фейсного метода
к вызову myCreateTimer класса
классу реализаTimerSessionBean
ции
Доступ к параме- intervalDuration в вызове
тру
timerService.createTimer
Доступ к переcontext.getTimerService()
менной
Модификация
TimerService timerService = context.
переменной
getTimerService();
Генерируемое ис- throws RemoteException, throws
ключение
RemoteException, CreateException
В качестве примера кода выбрано приложение Timer Service
(точнее, его серверная часть) из сборника примеров от Sun
Microsystems для платформы J2EE 1.4 (http://java.sun.com/
javaee/downloads/index.jsp). Пример посвящен реализации временного планирования генерации сообщений для всех типов
EJB, за исключением сессионных бинов с состоянием.
28
На рис. 10 представлены классы примера, а на рис. 11 – статическая структура этой модели с помощью графа (за исключением
пустых методов и конструктора класса TimerSessionBean).
1.4.2. Построение множества типовых графов
Включим во множество типовых графов один граф, приведенный на рис. 12. Этот граф будет определять допустимые отношения сущностей в правильной Java-программе.
1.4.3. Построение множества антитиповых графов
Каждый антитиповый граф будет посвящен описанию
определенного ограничения на отношения в корректной Javaпрограмме. Некоторые типичные примеры таких ограничений
представлены ниже:
public interface TimerSession extends EJBObject {
public void myCreateTimer (long intervalDuration ) throws
RemoteException ;
}
public interface TimerSessionHome extends EJBHome {
TimerSession create () throws RemoteException , CreateException ;
}
public class TimerSessionBean implements SessionBean , TimedObject
{
private SessionContext context ;
public void myCreateTimer (long intervalDuration ) {
System.out.println("TimerSessionBean : start createTimer
");
TimerService timerService = context.getTimerService ();
Timer timer = timerService .createTimer (intervalDuration ,
"created timer ");
}
public void ejbTimeout (Timer timer ) {
System.out.println("TimerSessionBean : ejbTimeout ");
}
public void setSessionContext (SessionContext sc ) {
System.out.println("TimerSessionBean : setSessionContext ");
context = sc;
}
public void ejbCreate () {
System.out.println("TimerSessionBean : ejbCreate ");
}
public TimerSessionBean () {}
public void ejbRemove () {}
public void ejbActivate () {}
public void ejbPassivate () {}
}
Рис. 10. Пример кода на Java
29
In
EJBObject
In
EJBHome
ge
ge
In
TimerSession
ty
Si
myCreateTimer
ra
Pa
intervalDuration
Bo
myCreateTimer
me
si
In
SessionBean
in
Cl
me
TimerSessionBean
Si
pa
setSessionContext me
Si
create
pa
In
TimedObject
in
In
TimerSessionHome ra
me
ty
Cl
CreateException
ra
context
ty
me
Cl
ty
SessionContext
me
li
Cl
Pa
sc
Bo
RemoteException
Bo
setSessionContext
Ty
Bo
long
ejbTimeout
li
pa
Pa
timer
Va
me
ty
Si
ejbTimeout
ejbCreate
li
Si
ejbCreate
Cl
Timer
Рис. 11. Граф, отражающий структуру кода на Java
NF
JO
HF
*O
HF
$M
4J
SBUZ
UZ
NFUZ
UZ
7B
5Z
UZ
U
MJ TJ
QB
EZGP
1B
BDVQ
BD
#P
FY
&Y
DPQB
Рис. 12. Типовый граф для кода на Java
1) поле не может быть определено в классе, если в нем, его
подклассах или суперклассах существует одноименное поле;
2) метод не может быть реализован дважды в одном и том же
классе;
3) метод не может получить доступ к полю, определенному в
подклассах данного класса;
4) класс, реализующий интерфейс, должен содержать реализации всех его методов.
30
$M
$M
NF
NF
NF
HF
7B
HF
NF
7B
$M
#P
NF
NF
$M
NF
NF
$M
$M
NF
HF
]
\BD]VQ^
$M
NF
#P
7B
4J
*O
NF
4J
JO
MJ
$M
NF
#P
#P
Рис. 13. Антитиповые графы Java-кода
Эти аксиомы представлены с помощью антитиповых графов
на рис. 13. Антитиповый граф (3) содержит два графовых выражения. Выражение Bo ¾¾¾¾
® Va определяет множество всех
*{ac|up}
непустых путей из Bo в Va, в которых последнее ребро имеет тип
aс (доступ к полю) или тип up (модификация поля).
1.5. Описание принципов проектирования
с помощью антитиповых графов
Механизм антитиповых графов может быть использован не
только для определения жестких ограничений на возможные
графовые структуры, но и с целью фильтрации программных
структур и сущностей. С помощью графовых выражений могут
быть описаны шаблоны структур, качество которых считается
низким (дефекты, антипаттерны и т. п.) или высоким (паттерны). Далее структура ПС может быть отфильтрована с целью
выявления фрагментов кода, имеющих низкое или высокое качество. Эта информация используется при оценке качества кода
(например, как общее число, удельный вес или процентное соотношение паттернов и антипаттернов и т. п.). Другим вариантом
применения механизма антитиповых графов является поиск
структур для рефакторинга.
31
1.6. Описание принципов проектирования
с помощью ролей
Как уже отмечалось, с помощью ролей вершин графов можно
вводить правила проектирования, описывающие типовые ограничения на возможные зависимости программных сущностей.
Этим способом можно специфицировать нежелательные, с точки зрения качества ПС, проектные решения. Проиллюстрируем
механизм использования ролей и правил на примере шаблонов
(типовых решений) в области объектно-ориентированного дизайна. В работах [25, 26] описаны шаблоны, имеющие отношение к
объектно-ориентированному программированию. Эти шаблоны
объединены в группы, соответствующие следующим типам: порождающие, структурные, поведенческие и архитектурные. Выберем для иллюстрации использования ролей и правил по одному шаблону каждого типа.
1.6.1. Варианты описания ролей в программном коде
Для того чтобы применять роли и правила использования ролей, необходимо аннотировать программные сущности идентификаторами ролей. В зависимости от парадигмы программирования и конкретного языка способы аннотации могут быть разными. Для объектно-ориентированной парадигмы варианты для
сопоставления ролей с программными сущностями могут быть
следующими.
1. Введение собственных тегов или атрибутов.
Этот вариант предполагает использование зависящей от языка программирования техники комментирования для введения
идентификаторов ролей программных сущностей. Например,
для языка Java спецификация того, что некоторый класс выполняет роли объекта предметной области из архитектурного шаблона «модель – представление – контроллер» и роль субъекта
из поведенческого шаблона «наблюдатель», могла бы выглядеть
так:
@roles (”domainObject, subject”)
public class Person {…}
Спецификация тех же ролей для класса на C# использует технику документирования, определенную для этого языка:
/// <roles>
/// domainObject,
/// subject
32
/// </roles>
public class Person {…}
2. Использование правил именования.
Другим способом идентификации ролей является применение
особых правил именования программных сущностей:
public class PersonDO {…}
Этот способ является менее удачным, так как ухудшает читабельность кода, особенно если сущность выполняет несколько
ролей, смешивая обязанности сущности с информацией о способе реализации этих обязанностей.
3. Распространение ролей агрегата на составляющие его элементы.
Для модульных языковых структур, например, пакетов
(Java) или пространств имен (C#) целесообразно использовать
собственные теги комментариев для идентификации ролей и распространять информацию о ролях на все элементы этого модуля. Этот вариант целесообразно применять для идентификации
ролей элементов архитектурных шаблонов, в силу соответствия
распределения по модулям выполняемым ролям.
В последующих примерах для простоты формирования правил условимся, что при генерации графа ПС, в том случае, если
методы одного объекта программы используют доступ к полям
или методам другого объекта программы, между вершинами,
представляющими эти объекты, порождаются ребра, имеющие
тип «использование», направленные от первого объекта ко второму.
1.6.2. Порождающий шаблон «абстрактная фабрика»
Абстрактная фабрика предоставляет интерфейс для создания
семейств взаимосвязанных или взаимозависимых объектов, не
специфицируя их конкретных классов [25]. Это шаблон, позволяющий изменять поведение системы, варьируя создаваемые
объекты, при этом сохраняя интерфейсы. Он дает возможность
создавать целые группы взаимосвязанных объектов, которые, будучи созданными одной фабрикой, реализуют общее поведение.
Шаблон реализуется созданием абстрактного класса Factory,
который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна и кнопки). Затем пишутся наследующиеся от него
классы, реализующие этот интерфейс.
33
На рис. 14 представлена диаграмма классов, отражающая
структуру абстрактной фабрики.
Классы шаблона:
– AbstractFactory – абстрактная фабрика, объявляет интерфейс для операций, создающих абстрактные объекты-продукты;
– ConcreteFactory – конкретная фабрика, реализует операции, создающие конкретные объекты-продукты;
– AbstractProduct – абстрактный продукт, объявляет интерфейс для типа объекта-продукта;
– ConcreteProduct – конкретный продукт, определяет объектпродукт, создаваемый соответствующей конкретной фабрикой;
реализует интерфейс AbstractProduct;
– Client – клиент, пользуется исключительно интерфейсами, которые объявлены в классах AbstractFactory и
AbstractProduct.
Отношения классов:
1) обычно во время выполнения создается единственный экземпляр класса ConcreteFactory. Эта конкретная фабрика создает объекты-продукты, имеющие вполне определенную реализацию. Для создания других видов объектов клиент должен воспользоваться другой конкретной фабрикой;
2) AbstractFactory передоверяет создание объектов-продуктов
своему подклассу ConcreteFactory.
Для достижения эффекта от использования этого шаблона необходимо, чтобы клиенты использовали экземпляры продуктов
через их абстрактные интерфейсы. Имена продуктов должны
быть известны только конкретной фабрике, в коде клиента они
упоминаться не должны.
Для описания принципа проектирования, связанного с
правильным использованием этого шаблона, введем роли
concreteFactory для всех объектов классов конкретных фабрик
и concreteProduct для всех объектов классов конкретных продуктов. Сформулируем правило, регламентирующее корректное
использование шаблона «абстрактная фабрика»: доступ к объектам конкретных продуктов могут иметь только объекты абстрактных фабрик. Формально: для ∀v:va(v)≠concreteFactory и
∀w:va(w)≠concreteProduct должно выполняться (v,w)∉(IVG)n.
1.6.3. Структурный шаблон «мост»
Мост – шаблон, позволяющий отделить интерфейс от реализации и изменять их независимо [26].
34
35
"CTUSBDU1SPEVDU#
1SPEVDU"
1SPEVDU#
$MJFOU
1SPEVDU#
1SPEVDU"
"CTUSBDU1SPEVDU"
Рис. 14. Структура шаблона «абстрактная фабрика»
$SFBUF1SPEVDU"
"CTUSBDU1SPEVDU"
$SFBUF1SPEVDU#
"CTUSBDU1SPEVDU#
$SFBUF1SPEVDU"
"CTUSBDU1SPEVDU"
$SFBUF1SPEVDU#
"CTUSBDU1SPEVDU#
$PODSFUF'BDUPSZ
$PODSFUF'BDUPSZ
$SFBUF1SPEVDU"
"CTUSBDU1SPEVDU"
$SFBUF1SPEVDU#
"CTUSBDU1SPEVDU#
"CTUSBDU'BDUPSZ
На рис. 15 представлена диаграмма классов, отражающая
структуру шаблона «мост».
Классы шаблона:
– Abstraction – абстракция, определяет интерфейс абстракции, хранит ссылку на объект типа Implementor, перенаправляет своему объекту Implementor запросы клиента;
– RefinedAbstraction – уточненная абстракция, расширяет
интерфейс, определенный абстракцией Abstraction;
– Implementor – реализатор, определяет интерфейс для классов реализации. Он не должен точно соответствовать интерфейсу
класса Abstraction. На самом деле, оба интерфейса могут быть
различными. Обычно интерфейс класса Implementor предоставляет только примитивные операции, а класс Abstraction определяет операции более высокого уровня, базирующиеся на этих
примитивах;
– ConcreteImplementor – конкретный реализатор, содержит
конкретную реализацию интерфейса класса Implementor.
Шаблон отделяет реализацию от интерфейса. Реализацию
можно конфигурировать во время выполнения, при этом объект может динамически изменять свою реализацию. Разделение
классов Abstraction и Implementor устраняет также зависимости
от реализации, устанавливаемые на этапе компиляции. Такое
разделение облегчает разбиение системы на слои и тем самым
позволяет улучшить ее структуру.
Для корректного использования этого шаблона необходимо,
чтобы клиенты имели доступ только к классу Abstraction. Введем
роли для обозначения компонент шаблона: abstraction для класса
$MJFOU
"CTUSBDUJPO
0QFSBUJPO
WPJE
3FGJOFE"CTUSBDUJPO
*NQMFNFOUPS
0QFSBUJPO*NQM
WPJE
$PODSFUF*NQMFNFOUPS"
$PODSFUF*NQMFNFOUPS#
0QFSBUJPO*NQM
WPJE
0QFSBUJPO*NQM
WPJE
Рис. 15. Структура шаблона «мост»
36
абстракции, refinedAbstraction для классов уточненных абстракций, implementor для класса реализации и concreteImplementor
для классов конкретных реализаций. Сформулируем правило,
согласно которому доступ к реализациям может быть определен
только для классов абстракций.
Для ∀v: va(v) ∉ {abstraction, refinedAbstraction} и ∀w: va(w) ∉ 
∉ {implementor, concreteImplementor} должно выполняться
(v,w)∉(IVG)n.
1.6.4. Поведенческий шаблон «наблюдатель»
«Наблюдатель» – шаблон, позволяющий создавать объекты,
зависимые от данного, которые получают извещения при каждой
смене состояния первичного объекта [26]. Шаблон определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие
от него оповещаются об этом и автоматически обновляются.
На рис. 16 представлена диаграмма классов, отражающая
структуру шаблона «наблюдатель».
Классы шаблона:
– Subject – субъект, располагает информацией о своих наблюдателях. За субъектом может «следить» любое число наблюдателей; предоставляет интерфейс для присоединения и отделения
наблюдателей;
4VCKFDU
"UUBDI0CTFSWFSP
WPJE
%FUBDI0CTFSWFSP
WPJE
WPJE
/PUJGZ
0CTFSWFS
PCTFSWFST
6QEBUF
WPJE
$PODSFUF4VCKFDU
s TVCKFDU4UBUF 4UBUF
(FU4UBUF
4UBUF
4FU4UBUF4UBUFT
WPJE
TVCKFDU
$PODSFUF0CTFSWFS
sPCTFSWFS4UBUF 4UBUF
6QEBUF
WPJE
Рис. 16. Структура шаблона «наблюдатель»
37
– Observer – наблюдатель, определяет интерфейс обновления
для объектов, которые должны быть уведомлены об изменении
субъекта;
– ConcreteSubject – конкретный субъект, сохраняет состояние, представляющее интерес для конкретного наблюдателя
ConcreteObserver; посылает информацию своим наблюдателям,
когда происходит изменение;
– ConcreteObserver – конкретный наблюдатель, хранит ссылку на объект класса ConcreteSubject; сохраняет данные, которые
должны быть согласованы с данными субъекта; реализует интерфейс обновления, определенный в классе Observer, чтобы поддерживать согласованность с субъектом.
Отношения классов:
1) объект ConcreteSubject уведомляет своих наблюдателей о
любом изменении, которое могло бы привести к рассогласованности состояний наблюдателя и субъекта;
2) после получения от конкретного субъекта уведомления об
изменении объект ConcreteObserver может запросить у субъекта дополнительную информацию, которую использует для того,
чтобы оказаться в состоянии, согласованном с состоянием субъекта.
Главное достоинство шаблона «наблюдатель» состоит в ослаблении связей компонент системы. Для правильного использования этого шаблона необходимо, чтобы субъект имел информацию лишь о том, что у него есть ряд наблюдателей, каждый из
которых подчиняется простому интерфейсу абстрактного класса
Observer. Субъекту не должны быть известны конкретные классы наблюдателей. Для формализации этого правила введем роли
класса субъекта – subject и классов конкретных наблюдателей –
concreteObserver. Сформулируем правило проектирования кода
с использованием шаблона «наблюдатель» формально: для ∀v:
:va(v)=subject и ∀w: va(w)=concreteObserver должно выполняться (v,w)∉(IVG)n.
1.6.5. Архитектурный шаблон
«модель – представление – контроллер»
Шаблон распределяет обработку взаимодействия с пользовательским интерфейсом между тремя участниками: моделью,
представлением и контроллером [26]. На рис. 18 представлена
диаграмма классов, отражающая структуру шаблона «модель –
представление – контроллер».
38
W
BCTUSBDU$MBTT
B
TVCKFDU
F
F
BCTUSBDU$MBTT
C
PCTFSWFS
BTTPD
F
HFOFSBM
M
F
HFOFSBM
O
W
W
DMBTT
D
DPODSFUF4VCKFDU
W
F
DMBTT
E
DPODSFUF0CTFSWFS
BTTPD
N
Рис. 17. Графовая модель шаблона «наблюдатель»
Компоненты шаблона:
– модель – это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведение, не связанные с пользовательским интерфейсом;
– представление – отображает содержимое модели средствами
графического интерфейса;
– контроллер – отвечает за изменение информации, получает
входные данные от пользователя, выполняет операции над моделью и указывает представлению на необходимость соответствующего обновления.
Шаблон реализует два принципиальных типа разделения: отделение представления от модели и отделение контроллера от
¨É¾½Ê˹»Ä¾ÆÁ¾
£ÇÆËÉÇÄľÉ
¥Ç½¾ÄÕ
Рис. 18. Структура шаблона «наблюдатель»
39
представления. Отделение представления от модели является одним из фундаментальных принципов проектирования программного обеспечения. Наличие подобного разделения весьма важно
по ряду причин. Во-первых, представление и модель относятся
к совершенно разным сферам программирования. Разработчик
представления думает о механизмах пользовательского интерфейса и о том, как сделать интерфейс приложения максимально
удобным для пользователя. Разработчик модели сосредотачивает
свое внимание на бизнес-правилах и, возможно, на взаимодействии с базой данных. Очевидно, при разработке модели и представления применяются разные библиотеки. Во-вторых, часто
пользователи хотят, чтобы, в зависимости от ситуации, одна и
та же информация могла быть отображена разными способами.
Отделение представления от модели позволяет разработать для
одного и того же кода модели несколько представлений, а точнее,
несколько абсолютно разных интерфейсов. В-третьих, объекты,
не имеющие визуального интерфейса, гораздо легче тестировать,
чем объекты с интерфейсом. Отделение представления от модели
позволяет легко протестировать всю логику домена, не прибегая к
таким нетривиальным механизмам, как средства написания сценариев для поддержки графического интерфейса пользователя.
Ключевым моментом в отделении представления от модели
является направление зависимостей: представление зависит от
модели, но модель не зависит от представления. Программисты,
занимающиеся разработкой модели, вообще не должны быть
осведомлены о том, какое представление будет использоваться.
Это существенно облегчает разработку модели и одновременно
упрощает последующее добавление новых представлений. Кроме того, это означает, что изменение представления не требует
изменения модели.
Отделение контроллера от представления не играет такой важной роли, как предыдущий тип разделения. Классическим примером необходимости подобного разделения является поддержка редактируемого и нередактируемого поведения. Этого можно
достичь при наличии одного представления и двух контроллеров
для двух вариантов использования, где контроллеры являются
стратегиями [25], используемыми представлением.
Для формализации правильного использования этого шаблона введем три роли: domain – для идентификации классов модели, view – для классов представления и controller – для классов
контроллера.
40
Формализуем правило необходимости отсутствия зависимости элементов модели от представления: для ∀v:va(v)=domain и
∀w:va(w)=view должно выполняться (v,w)∉(IVG)n. Правило отсутствия зависимости элементов контроллера от представления
будет выглядеть следующим образом: для ∀v:va(v)=controller и
∀w:va(w)=view должно выполняться (v,w)∉(IVG)n. Так как обычно классы модели, представления и контроллера образуют три
разных слоя, декомпозиция на которые достигается применением
пакетов (Java) или пространств имен (C#), то целесообразно присваивать метки ролей не поэлементно, а определенному пакету
или пространству имен, предполагая распространение этой роли
на все принадлежащие пакету или пространству имен элементы.
41
Глава 2. Моделирование
качества программных средств
Качество вообще и связанные с ним методологии являются
предметом научной дисциплины под названием квалитология.
Составляют квалитологию следующие научные направления
(рис. 19):
– теория качества, исследующая природу качества, различные концептуальные аспекты качества продукции и услуг;
– квалиметрия, изучающая методы количественного оценивания качества;
– метрология, изучающая методы измерения качества;
– теория управления качеством, занимающаяся разработкой
формальных моделей и методов обеспечения и управления качеством.
Компьютерная система определяется современными международными стандартами в области качества (например,
ISO/IEC 25000) как взаимосвязанное множество аппаратных
средств и программного обеспечения, находящееся под одним и
тем же управлением, которое распределяет общую функциональность [26]. Согласно этим стандартам, программное обеспечение
состоит из программы, данных и документации. В дальнейшем
изложении главным объектом исследования будет выступать
программа или ПС, при этом эти два понятия будут считаться эквивалентными.
В настоящий момент используются несколько определений
понятия качества ПС, которые в целом совместимы друг с другом. Обобщая определения стандартов, можно заключить, что
£»¹ÄÁËÇÄǼÁØ
«¾ÇÉÁØùоÊË»¹
§ºÒ¹Ø
™Æ¹ÄÁÀ
£»¹ÄÁžËÉÁØ
ªÈ¾ÏÁ¹ÄÕÆÔ¾
§º¾ÊȾоÆÁ¾
¥¾ËÉÇÄǼÁØ
¨É¾½Å¾ËÆÔ¾
¨ÉǼÆÇÀÁÉÇ»¹ÆÁ¾
Рис. 19. Структура квалитологии
42
«¾ÇÉÁØÌÈɹ»Ä¾ÆÁØ
ùоÊË»ÇÅ
¨Ç»ÔѾÆÁ¾
качество программного обеспечения – это способность программного продукта удовлетворять установленные или предполагаемые потребности при использовании в заданных условиях. Наиболее современные стандарты в области качества ПС (например,
ISO/IEC 25000) используют понятия внешнего, внутреннего качества и качества в использовании.
Внешнее качество – способность ПС реализовать такое поведение системы, которое бы удовлетворило установленные или
предполагаемые потребности при использовании системы в заданных условиях.
Внутреннее качество – способность множества статических
атрибутов (т. е. неотъемлемых свойств или характеристик сущности, которые могут быть охарактеризованы качественно или
количественно человеком или автоматически) ПС обеспечить
установленные или предполагаемые потребности при использовании ПС в заданных условиях.
Качество в использовании – степень, в которой ПС, применяемое определенными пользователями, соответствует их потребностям в достижении заданных целей в контексте эффективности,
продуктивности, безопасности и достоверности.
2.1. Существующие модели и стандарты качества ПС
Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методологии их оценивания. В целях регламентации
оценивания качества ПС с середины 1970-х годов ведется работа по созданию моделей качества ПС. Наиболее современный
стандарт – ISO/IEC 25000 – характеризует модель качества как
определенный набор характеристик (т. е. категорий атрибутов,
которые имеют отношение к качеству ПС) и отношений между
ними, которые обеспечивают основу для спецификации требований к качеству и оценивания качества [26].
Некоторые из появившихся за три десятилетия моделей качества были направлены на решение определенных корпоративных задач, другие с помощью адаптации использовались в
разнородных проектах по созданию ПС, третьи легли в основу
отраслевых, государственных или международных стандартов
качества.
В России в области обеспечения качества программ в основном применяются стандарты ГОСТ Р ИСО/МЭК 9126-93 и ГОСТ
43
28195-89, в целом являющиеся устаревшими по сравнению с мировым уровнем на 5–10 лет [28].
В настоящий момент наиболее «зрелым» международным
стандартом в области качества ПС является стандарт ISO/IEC
25000:2005.
2.1.1. Модели типа «факторы – критерии – метрики»
По своей природе модели качества имеют иерархическую
структуру. Основным принципом такого рода моделей является
возможность декомпозиции каждого атрибута качества на набор
факторов, которые, в свою очередь, декомпозируются на наборы
критериев. Критерии могут быть сопоставлены с множеством
метрик и таким образом оценены. В соответствии с наименованиями основных составляющих элементов, такие модели обычно называют модели «факторы – критерии – метрики» (factor –
criteria – metrics – FCM).
Первой широко известной моделью качества ПС стала модель,
предложенная в 1977 г. Дж. МакКолом [31] (рис. 20).
В этой модели характеристики качества разделены на три
группы (рис. 21):
1) факторы, описывающие ПС с позиции пользователя и задающие требования к ПС;
2) критерии, описывающие ПС с позиции разработчиков и задаваемые как цели;
3) метрики, используемые для количественного описания и
измерения качества.
ªÇÈÉǻǿ½¹¾ÅÇÊËÕ
ªÈÇÊǺÆÇÊËÕûÀ¹ÁÅǽ¾ÂÊË»Á×
«¾ÊËÁÉ̾ÅÇÊËÕ
œÁºÃÇÊËÕ
¨Ç»ËÇÉÆǾÁÊÈÇÄÕÀÇ»¹ÆÁ¾
©¾»ÁÀÁÁ ›Æ¾½É¾ÆÁ¾
¨¾É¾ÆÇÊÁÅÇÊËÕ
­ÌÆÃÏÁÇÆÁÉÇ»¹ÆÁ¾
£ÇÉɾÃËÆÇÊËÕ ¦¹½¾¿ÆÇÊËÕ
¶Í;ÃËÁ»ÆÇÊËÕ ¯¾ÄÇÊËÆÇÊËÕ
¨É¹ÃËÁÐÆÇÊËÕ
Рис. 20. Треугольник МакКола
44
£ÇÉɾÃËÆÇÊËÕ
«É¹ÊÊÁÉ̾ÅÇÊËÕ
­ÌÆÃÏÁÇƹÄÕƹØÈÇÄÆÇ˹
¦¹½¾¿ÆÇÊËÕ
­ÌÆÃÏÁÇÆÁ
ÉÇ»¹ÆÁ¾
ÈÉǽÌÃ˹
¶Í;ÃËÁ»ÆÇÊËÕ
¯¾ÄÇÊËÆÇÊËÕ
¬½ÇºÊË»ÇɹºÇËÔ
ªÇ¼Ä¹ÊÇ»¹ÆÆÇÊËÕ
«ÇÐÆÇÊËÕ
¬ÊËÇÂÐÁ»ÇÊËÕÃÇÑÁºÃ¹Å
›É¾Å¾ÆƹØÖÍ;ÃËÁ»ÆÇÊËÕɹºÇËÔ
žÅÃÇÊËƹØÖÍ;ÃËÁ»ÆÇÊËÕɹºÇËÔ
£ÇÆËÉÇÄÕ½ÇÊËÌȹ
™Ì½Á˽ÇÊËÌȹ
¬½ÇºÊË»ÇÁÊÈÇÄÕÀÇ»¹ÆÁØ
¬½ÇºÊË»ÇǺÌоÆÁØ
£ÇÅÅÌÆÁùËÁ»ÆÇÊËÕ
¨ÉÇÊËÇ˹ɹºÇËÔ
ªÇÈÉǻǿ½¹¾ÅÇÊËÕ
£É¹ËÃÇÊËÕ
¨ÇÄÆÇ˹ÈÉÇËÇÃÇÄÁÉÇ»¹ÆÁØÇÑÁºÇÃ
©¾»ÁÀÁÁ
ÈÉǽÌÃ˹
«¾ÊËÁÉ̾ÅÇÊËÕ
ª¹ÅÇÇÈÁÊÔ»¹¾ÅÇÊËÕ
©¹ÊÑÁÉؾÅÇÊËÕ
œÁºÃÇÊËÕ
±ÁÉÇ˹ǺĹÊËÁÈÉÁžƾÆÁØ
¥Ç½ÌÄÕÆÇÊËÕ
¨¾É¾ÆÇÊÁÅÇÊËÕ
›Æ¾½É¾ÆÁ¾
ÈÉǽÌÃ˹
¨Ç»ËÇÉÆǾÁÊÈÇÄÕÀÇ»¹ÆÁ¾
¦¾À¹»ÁÊÁÅÇÊËÕÇ˹ÈȹɹËÆÇÂÈĹËÍÇÉÅÔ
ªË¾È¾ÆÕÊ˹ƽ¹ÉËÆÇÊËÁÁÆ˾É;ÂÊÇ»
ªÈÇÊǺÆÇÊËÕ
ûÀ¹ÁÅǽ¾ÂÊË»Á×
­¹ÃËÇÉÔ
¦¾À¹»ÁÊÁÅÇÊËÕÇËÈÉǼɹÅÅÆÇÂÈĹËÍÇÉÅÔ
£ÉÁ˾ÉÁÁ
ªË¾È¾ÆÕÊ˹ƽ¹ÉËÆÇÊËÁÍÇÉŹËÇ»½¹ÆÆÔÎ
¥¾ËÉÁÃÁ
Рис. 21. Модель качества МакКола
45
Факторы качества (всего 11) объединяются в три группы по
различным способам работы пользователей с ПС. Полученная
структура изображается в виде так называемого треугольника
МакКола.
Критерии качества – это количественные значения факторов,
поставленные в качестве целей при разработке.
Объективно оценить или измерить факторы качества непосредственно довольно трудно. Поэтому МакКол ввел метрики качества, которые, с его точки зрения, легче измерять и оценивать.
Оценки в его шкале принимают значения от 0 до 10. Каждая метрика влияет на оценку нескольких факторов качества. Числовое выражение фактора представляет собой линейную комбинацию значений влияющих на него метрик. Коэффициенты этого
выражения определяются по-разному для разных организаций,
команд разработки, видов ПС, используемых процессов и т. п.
Модель МакКола использовалась в ряде крупных проектов
Министерства обороны США. Она была реализована в проектах подразделения электронных систем ВВС США и компании
«Дженерал Электрикс» в целях повышения качества ПС, при
этом главной задачей внедрения модели было достижение измеримости показателей качества ПС.
В 1978 г. Б. Боем [32, 33] предложил свою модель, по существу представляющую собой расширение модели МакКола.
Атрибуты качества подразделяются по способу использования ПО (primary use). Определено 19 промежуточных атрибутов
(intermidiate construct), включающих все 11 факторов качества
по МакКолу. Промежуточные атрибуты разделяются на примитивные (primitive construct), которые, в свою очередь, могут
быть оценены на основе метрик (рис. 22).
В дополнение к факторам МакКола атрибуты качества по Боему включают следующие: ясность (clarity), удобство внесения изменений (modifiability), документированность (documentation),
способность к восстановлению функций (resilience), понятность
(understandability), адекватность (validity), функциональность
(functionality), универсальность (generality), экономическая эффективность (economy). Помимо этого, в модель добавлены характеристики производительности аппаратных средств, отсутствующие в модели МакКола.
Валидация обеих моделей основывалась, скорее, на здравом
смысле, чем на каких-либо формальных техниках.
46
¦¾À¹»ÁÊÁÅÇÊËÕÇ˹ÈȹɹËÆÇÂÈĹËÍÇÉÅÔ
¨¾É¾ÆÇÊÁÅÇÊËÕ
ª¹ÅǽÇÊ˹ËÇÐÆÇÊËÕ
«ÇÐÆÇÊËÕ
­ÌÆÃÏÁÇƹÄÕƹØÈÇÄÆÇ˹
¦¹½¾¿ÆÇÊËÕ
ŸÁ»ÌоÊËÕ Ï¾ÄÇÊËÆÇÊËÕ
ªÇ¼Ä¹ÊÇ»¹ÆÆÇÊËÕ
§ºÒ¹Ø
ÈÇľÀÆÇÊËÕ
¨ÇľÀÆÇÊËÕ
¶Í;ÃËÁ»ÆÇÊËÕ
¡½¾ÆËÁÍÁÏÁÉ̾ÅÇÊËÕ
¶Í;ÃËÁ»ÆÇÊËÕÁÊÈÇÄÕÀÇ»¹ÆÁØɾÊÌÉÊÇ»
¶É¼ÇÆÇÅÁÐÆÇÊËÕ
ÇÊËÌÈÆÇÊËÕ
£ÇÅÅÌÆÁùËÁ»ÆÇÊËÕ
«¾ÊËÁÉ̾ÅÇÊËÕ
ª¹ÅÇÇÈÁÊÔ»¹¾ÅÇÊËÕ
ªËÉÌÃËÌÉÁÉ̾ÅÇÊËÕ
ªÇÈÉǻǿ
½¹¾ÅÇÊËÕ
¨ÇÆØËÆÇÊËÕ
£É¹ËÃÇÊËÕ
¬½ÇºÇÐÁ˹¾ÅÇÊËÕ
¥Ç½ÁÍÁÏÁ
É̾ÅÇÊËÕ
­¹ÃËÇÉÔ
£ÉÁ˾ÉÁÁ
©¹ÊÑÁÉؾÅÇÊËÕ
¥¾ËÉÁÃÁ
Рис. 22. Модель качества Боема (фрагмент)
В 1987 г. компания «Хьюлетт Паккард» предложила FURPS –
индустриальную интерпретацию, основанную на моделях МакКола и Боема [33]. Модель содержит пять высокоуровневых
атрибутов (функциональность, используемость, надежность,
производительность и сопровождаемость), которые детализируются 27 атрибутами низкого уровня.
47
Модель Т. Гилба [35] в целом соответствует общей концепции
моделей «фактор – критерии – метрики», но имеет несколько
важных отличий. Модель качества встраивается в проектную
спецификацию, а каждый атрибут должен быть измеримым и
детализироваться в процессе ЖЦ ПС. Помимо атрибутов качества, в модель входят атрибуты ресурсов. Модель основана на
четырех качественных (применимость, полезность, приспособляемость, удобство использования) и четырех ресурсных
(время, бюджет, исполнители, средства разработки) атрибутах,
которые можно расширять. Гилб разработал семь принципов
использования модели, главным из которых является принцип
измеримости: все атрибуты могут и должны быть на практике
измеримыми. По мнению Гилба, всегда можно найти подходящее измерение для атрибута, если же такового нет, то это не
атрибут, а подхарактеристика, нуждающаяся в дальнейшей декомпозиции.
В 1990 г. С. Келлер [36] описал расширение модели МакКола
и ввел несколько важных концепций качества. Основой новой
концепции Келлера является коммуникабельность. Идея состоит в определении двойной нотации для описания каталогов
характеристик и подхарактеристик для пользователей и для
разработчиков. Другие подобные работы [37] также используют
понятие двойственности (но не двусмысленности) как свойства,
необходимого для достижения коммуникабельности.
2.1.2. Модели типа «цель – вопрос – метрика»
Модель «цель – вопрос – метрика» (goal/question/metric –
GQM) была разработана с целью идентификации дефектов в ПС
в Годдардовском центре космических полетов NASA. Задача модели – служить основой для выработки решений об управлении
процессами разработки ПС на основе измерений. Модель GQM
предоставляет основу для транслирования целей разработки ПС
во множества вопросов и метрик. Модель также имеет иерархическую трехуровневую структуру (рис. 23).
1. Концептуальный уровень (цели). Цели представляют собой
абстрактные атрибуты, выражающие вектор направления разработки, и могут быть сопоставлены с различными объектами
(ПС, процессами разработки, ресурсами разработки и т. п.). Примерами целей могут служить «Переносимость», «Надежность»,
«Тестируемость».
48
¥¾ËÉÁù ¥¾ËÉÁù ›ÇÈÉÇÊ ¥¾ËÉÁù ¥¾ËÉÁù ¯¾ÄÕ ›ÇÈÉÇÊ ¥¾ËÉÁù ¥¾ËÉÁù ›ÇÈÉÇÊ ¥¾ËÉÁù ¥¾ËÉÁù ¥¾ËÉÁù ›ÇÈÉÇÊ ¯¾ÄÕ ¥¾ËÉÁù ›ÇÈÉÇÊ ¥¾ËÉÁù ¥¾ËÉÁù ¯¾ÄÁ
›ÇÈÉÇÊÔ
¥¾ËÉÁÃÁ
Рис. 23. Схема модели качества GQM
2. Операционный уровень (вопросы). Вопросы используются
для описания способа достижения целей; характеризуют объекты измерений (ПС, процессы, ресурсы и т. п.) в соответствии с
выбранным фактором качества и описывают их качество с некоторой точки зрения.
3. Количественный уровень (метрики). Метрики представляют
собой процедуры, формулы или алгоритмы, которые могут быть
использованы для ответа на вопросы количественным образом.
Метрики могут быть как объективными, так и субъективными.
Согласно модели, каждый вопрос должен быть сопоставлен
только с одной целью, а метрики могут быть сопоставлены с разными вопросами.
49
Модели GQM и FCM являются сопоставимыми. Цели и вопросы соответствуют факторам и критериям. Вместе с тем модели
FCM предполагают повторное использование в нескольких проектах, в то время как с помощью моделей типа GQM, как правило,
создаются разные проекции для одного проекта. Несколько моделей типа GQM для одного проекта могут иметь общие вопросы
и метрики, если они являются разными проекциями оценки проекта. Примеры применений GQM-моделей в банковской и аэрокосмической сферах можно найти в работах [38, 39].
2.1.3. Модели типа «процесс/продукт»
Некоторые исследователи разрабатывали модели не только
для оценивания качества, но и для управления процессом разработки ПС. Эти подходы характеризуются направленностью на
оценку внутренних атрибутов ПС и их отображение на внешние
атрибуты. Основными моделями в рамках этих подходов выступают модель Р. Дроми [40] и метод SQUID [41].
Модель Дроми [40] была предложена в 1996 г. (рис. 24). Согласно Г. Дроми, высокоуровневые показатели качества, такие
как надежность, переносимость, не могут быть непосредственно обеспечены ПС. Вместо этого необходимо определить набор
свойств ПС, достижение которых приводит к выполнению определенного уровня значений такого рода показателей. Модель
Дроми также иерархична по своей природе, но заметно отличается от других иерархических моделей качества. В этом подходе
модель качества строится снизу вверх. Во-первых, определяется
множество компонентов, которые составляют ПС. Некоторые
из них могут быть атомарными, некоторые – состоять из других компонент. Во-вторых, определяются те свойства каждого
£ÇÅÈÇƾÆË
ª»ÇÂÊË»¹
»ÄÁØ×ÒÁ¾
ƹùоÊË»Ç
¥Ç½¾ÄÕ¨ª
£ÇÅÈÇƾÆË
ª»ÇÂÊË»¹
»ÄÁØ×ÒÁ¾
ƹùоÊË»Ç
ª»ØÀÁ
›ÔÊÇÃÇÌÉǻƾ»Ô¾
¹ËÉÁºÌËÔ
ùоÊË»¹
Рис. 24. Элементы модели качества Дроми
50
компонента, которые влияют на качество этого компонента. Наконец, в силу того, что обычно качество ПС описывается в терминах высокоуровневых характеристик, вводится множество
непересекающихся, обладающих полнотой и согласованностью
высокоуровневых атрибутов.
Модель качества дополняется связью между свойствами ПС
и высокоуровневыми атрибутами качества. Каждая такая связь
должна быть проверена опытным путем для каждого свойства
ПС. Связь между свойствами ПС и атрибутами композиционных
компонентов ПС определяет качество ПС в целом.
Так как Дроми ориентировал свой подход на поддержку разработки ПС, он ввел три модели качества: модель качества требований, модель качества проекта и модель качества реализации.
Каждая модель отнесена к соответствующему этапу ЖЦ и содержит собственный набор атрибутов.
Метод SQUID [41] охватывает процессы планирования, управления и оценивания качества. SQUID определяет качество как поведенческую характеристику ПС, необходимую пользователям.
Как и рассмотренные модели, метод SQUID определяет качество
в терминах высокоуровневых характеристик, которые должны
детализироваться до тех пор, пока не смогут быть измерены.
Собственная модель качества у SQUID отсутствует, предлагается
воспользоваться одной из наиболее подходящих из числа существующих (рис. 25).
›ÆÌËɾÆÆØØ
ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹
›ÆÌËɾÆÆØØ
ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹ ›ÆÌËɾÆÆØØ
ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹ ›ÆÌËɾÆÆØØ
ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹ ›ÆÌËɾÆÆØØ
ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹ ›ÆÌËɾÆÆÁÂ
¹ËÉÁºÌË
ùоÊË»¹ ›ÆÌËɾÆÆÁÂ
¹ËÉÁºÌË
ùоÊË»¹ ›Æ¾ÑÆØØ
ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹
›Æ¾ÑÆØØ
›Æ¾ÑÆØØ
ιɹÃ˾ÉÁÊËÁù ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹ ùоÊË»¹ ›Æ¾ÑÆØØ
›Æ¾ÑÆØØ
ιɹÃ˾ÉÁÊËÁù ιɹÃ˾ÉÁÊËÁù
ùоÊË»¹ ùоÊË»¹ ›Æ¾ÑÆÁÂ
¹ËÉÁºÌË
ùоÊË»¹ ›Æ¾ÑÆÁÂ
¹ËÉÁºÌË
ùоÊË»¹ Рис. 25. Элементы модели качества SQUID
51
В SQUID те характеристики, которые определяют поведение
ПС, носят название внешних характеристик качества (например, простота использования, надежность). Характеристики,
относящиеся к разработке ПС, называются внутренними (например, структурная сложность, размер, тестовое покрытие). Пользователь метода должен определить, как именно внутренние характеристики влияют на внешние путем задания связей между
ними в модели качества.
Метод SQUID описывает требования к качеству ПС путем задания целей для внешних характеристик. Затем эти цели реализуются путем определения и отслеживания целей для внутренних характеристик. Последнее достигается путем измерений
значения внутренних характеристик.
2.1.4. Стандарт IEEE 1061
Стандарт IEEE 1061 был создан в 1998 г. организацией IEEE
(Institute of Electrical and Electronics Engineers) [42]. Стандарт
описывает достаточно открытую и гибкую иерархическую структуру модели качества, имеющую в качестве верхнего уровня факторы качества, которые декомпозируются на подфакторы качества и метрики. Каждый уровень может быть декомпозирован на
подуровни (рис. 26). В отличие от стандарта ISO/IEC 9126:2001-4
[26–29], который жестко фиксирует набор характеристик и подхарактеристик, данный стандарт не ограничивает множества
£¹Ð¾Ê˻Ǩª
­¹ÃËÇÉ
ùоÊË»¹
­¹ÃËÇÉ
ùоÊË»¹
­¹ÃËÇÉ
ùоÊË»¹
¨Ç½Í¹ÃËÇÉ
ùоÊË»¹
¨Ç½Í¹ÃËÇÉ
ùоÊË»¹
¥¾ËÉÁù
¨Ç½Í¹ÃËÇÉ
ùоÊË»¹
¨Ç½Í¹ÃËÇÉ
ùоÊË»¹
¥¾ËÉÁù
¥¾ËÉÁù
¥¾ËÉÁù
¥¾ËÉÁù
¥¾ËÉÁù
Рис. 26. Элементы модели качества IEEE 1061
52
факторов и подфакторов и допускает добавлять новые и удалять
существующие факторы и подфакторы. Стандарт содержит описание методики, предназначенной для использования описываемой модели совместно с моделью GQM. Интересной особенностью является возможность непосредственного оценивания с
помощью метрик самых верхних уровней иерархии факторов и
подфакторов, т. е. возможность декомпозиции высокоуровневого элемента на набор разноуровневых.
2.1.5. ГОСТ 28195-89
ГОСТ 28195-89 [43] устанавливает общие положения по оценке качества программных средств, описывает процессы планирования уровня качества, контроля значений показателей качества
в процессе разработки и испытаний. ГОСТ 28195-89 использует
модель качества типа «факторы – критерии – метрики».
Показатели качества разбиты на 6 групп и 19 комплексных
показателей. Группы определяют пользовательские свойства
программных средств, комплексные показатели – программные
свойства, от значений которых зависит значение пользовательских свойств.
В зависимости от типа программного средства (по ОКП – общероссийскому классификатору продукции) выбирается номенклатура показателей качества, которая должна быть зафиксирована
в ТЗ (техническом задании) на разработку ПС. В табл. 3 приводятся типы программных средств по ОКП и соответствующие им
номенклатуры показателей.
Таблица 3
Номенклатура показателей качества для групп ПС
Показатель
Устойчивость
функционирования
Применяемость показателя по подклассам (группам) ПС
5011 5012 5013 5014 5015 5016 5017 503 504 505 506
+
+
+
+
+
+
+
–
±
+
±
Работоспособность
+
+
+
+
+
+
+
+
+
+
+
Структурность
±
±
±
±
±
±
±
±
±
±
±
Простота конструкции
±
±
±
±
±
±
±
–
±
±
±
Наглядность
±
±
±
±
±
±
±
–
±
±
±
Повторяемость
±
±
±
±
±
±
±
±
±
±
±
53
Окончание табл. 3
Показатель
Применяемость показателя по подклассам (группам) ПС
5011 5012 5013 5014 5015 5016 5017 503 504 505 506
Легкость освоения
±
±
±
+
+
+
+
±
+
±
±
Доступность эксплуатационных
программных документов
+
+
+
+
+
+
+
+
+
+
+
Удобство эксплуатации и обслуживания
+
+
±
+
+
+
+
–
+
+
±
Уровень автоматизации
±
±
±
±
±
±
±
–
±
±
±
Временная эффективность
±
±
±
±
±
±
±
±
±
±
±
Ресурсоемкость
+
+
+
±
±
+
±
–
±
±
±
Гибкость
–
±
–
±
±
–
–
–
+
±
±
Мобильность
±
±
±
±
±
±
±
±
±
±
±
Модифицируемость
+
+
±
±
±
±
±
–
±
±
±
Полнота реализации
+
+
+
+
+
+
+
+
+
+
+
Согласованность
+
+
+
+
+
+
+
+
+
+
+
Логическая корректность
+
+
+
+
+
+
+
+
+
+
+
Проверенность
+
+
+
+
+
+
+
+
+
+
+
Примечание: «+» означает применяемость; «–» – неприменяемость соответствующих показателей качества ПС; «±» – ограниченную применяемость. Выбор показателей качества ПС для подкласса 509 (прочие ПС) осуществляется в
зависимости от их назначения с учетом требований областей применения. Наименование подклассов (групп) ПС по ОКП: 5011 – операционные системы и средства их расширения; 5012 – программные средства управления базами данных;
5013 – инструментально-технологические средства программирования; 5014 –
ПС интерфейса и управления коммуникациями; 5015 – ПС организации вычислительного процесса (планирования, контроля); 5016 – сервисные программы;
5017 – ПС обслуживания вычислительной техники; 503 – прикладные программы для научных исследований; 504 – прикладные программы для проектирования; 505 – прикладные программы для управления техническими устройствами
и технологическими процессами; 506 – прикладные программы для решения
экономических задач.
54
¬ÊËÇÂÐÁ»ÇÊËÕ
ÍÌÆÃÏÁÇÆÁÉÇ»¹ÆÁØ
¨ÇùÀ¹Ë¾ÄÁ
ƹ½¾¿ÆÇÊËÁ
¨ÇùÀ¹Ë¾ÄÁ
̽ǺÊË»¹
ÈÉÁžƾÆÁØ
ªÉ¾½ÊË»¹»ÇÊÊ˹ÆǻľÆÁØ
ÈÉÁÇÑÁºÃ¹Î»Ç»ÎǽÆÔÎ
½¹ÆÆÔÎ
¦¹ÄÁÐÁ¾ËɾºÇ»¹ÆÁÂ
ÃÊɾ½ÊË»¹Å
»ÇÊÊ˹ÆǻľÆÁØÈÉÁ
ÇÑÁºÃ¹Î»Ç»ÎǽÆÔÎ
½¹ÆÆÔÎ
ªÉ¾½ÊË»¹»ÇÊÊ˹ÆǻľÆÁØ
ÈÉÁʺÇØÎǺÇÉ̽ǻ¹ÆÁØ
›ÇÀÅÇ¿ÆÇÊËÕǺɹºÇËÃÁ
ÇÑÁºÇÐÆÔÎÊÁË̹ÏÁÂ
¨ÇÄÆÇ˹ǺɹºÇËÃÁ
ÇÑÁºÇÐÆÔÎÊÁË̹ÏÁÂ
©¹ºÇËÇÊÈÇÊǺÆÇÊËÕ
¨ÇùÀ¹Ë¾ÄÁ
ÖÍ;ÃËÁ»ÆÇÊËÁ
¨ÇùÀ¹Ë¾ÄÁ
ÊÇÈÉǻǿ½¹¾ÅÇÊËÁ
­ÌÆÃÏÁÇÆÁÉÇ»¹ÆÁ¾
»À¹½¹ÆÆÔÎɾ¿ÁŹÎ
§º¾ÊȾоÆÁ¾ÇºÉ¹ºÇËÃÁ
À¹½¹ÆÆǼÇǺӾŹ
ÁÆÍÇÉŹÏÁÁ
£ÇÅÈľÃÊÆÔ¾
ÈÇùÀ¹Ë¾ÄÁ
ÃÉÁ˾ÉÁÁ
§ºØÀ¹Ë¾ÄÕÆÔ¾ÖľžÆËÔ
œÉÌÈÈÔ͹ÃËÇÉÔ
¥¾ËÉÁÃÁ
§Ï¾ÆÇÐÆÔ¾
ÖľžÆËÔ
ªÈɹ»ÇÐÆÔ¾ÖľžÆËÔ
Рис. 27. Пример модели качества по ГОСТ 28195
В стандарте приводится справочное приложение, которое содержит методику оценивания качества программных средств.
Для каждого показателя качества приводятся метрики (третий
уровень детализации) и для каждой метрики указываются оценочные элементы (четвертый уровень детализации), которые и
предлагается оценивать.
На рис. 27 приведен пример детализации требований к качеству ПС.
Согласно ГОСТ 28195, качество ПС определяется путем сравнения полученных расчетных значений показателей с соответствующими базовыми значениями показателей существующего
аналога или расчетного ПС, принимаемого за эталонный образец. Значения базовых показателей ПС должны соответствовать
значениям показателей, отражающих современный уровень качества и прогнозируемый мировой уровень. В качестве аналогов
выбираются реально существующие ПС того же функционального назначения, что и сравниваемое, с такими же основными параметрами, подобной структуры и применяемые в схожих условиях эксплуатации.
55
2.1.6. Стандарты ISO/IEC 9126, ISO/IEC 25000
В России в настоящее время в области качества ПС, помимо
ГОСТ 28195-89, действует стандарт ГОСТ Р ИСО/МЭК 9126-93
«Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению».
Этот стандарт является адаптацией международного стандарта
ISO/IEC 9126-91. Для замены стандарта редакции 1991 г. ИСО
в 2001–2004 гг. выпустила стандарт ISO 9126-1-4 [26–29], где
основные концепции были уточнены, детализированы и расширены. В 2005 г. для замены стандарта ISO/IEC 9126:2001-4 был
*40*&$O
œÉÌÈȹÅǽ¾ÄÁ
ùоÊË»¹
*40*&$O
œÄ¹»Æ¹Ø¼ÉÌÈȹùоÊË»¹
ÈÉǼɹÅÅÆÔÎÈÉǽÌÃËÇ»
*40*&$O
œÉÌÈȹËɾºÇ»¹ÆÁÂ
ÃùоÊË»Ì
§ºÒ¾¾
ÇÈÁʹÆÁ¾
*40*&$O
œÉÌÈȹÇϾÆÃÁ
ùоÊË»¹
¨Ä¹ÆÁÉÇ»¹ÆÁ¾
ÁÌÈɹ»Ä¾ÆÁ¾
*40*&$O
œÉÌÈȹžËÉÁÃ
ùоÊË»¹
Рис. 28. Архитектура ISO/IEC 25000
£ÇÆ˾ÃÊË
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
£¹Ð¾ÊË»Ç ›ÄÁØ¾Ë ›ÆÌËɾÆƾ¾ ›ÄÁؾË
ƹ
ƹ
ÈÉÇϾÊʹ
ùоÊË»Ç
¥¾ËÉÁÃÁ
ùоÊË»¹
ÈÉÇϾÊʹ
¥¾ËÉÁÃÁ
»ÆÌËɾÆƾ¼Ç
ùоÊË»¹
›Æ¾Ñƾ¾ ›ÄÁØ¾Ë £¹Ð¾Ê˻ǻ
ƹ
ùоÊË»Ç
ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
¥¾ËÉÁÃÁ
»Æ¾Ñƾ¼Ç
ùоÊË»¹
¥¾ËÉÁÃÁ
ùоÊË»¹ÈÉÁ
ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
Рис. 29. Взаимосвязь моделей качества по ISO/IEC 9126,
ISO/IEC 25000
56
издан стандарт ISO/IEC 25000:2005 «Требования и оценка качества программных продуктов» [25, 44].
Стандарт ISO/IEC 25000 состоит из пяти групп, каждая из которых может состоять из одного или нескольких документов [25].
На рис. 28 приведена архитектура стандарта ISO/IEC 25000. На
рис. 29 приведена схема взаимосвязи трех моделей качества согласно ISO/IEC 9126 и ISO/IEC 25000.
Одна из целей новой серии состоит в согласовании терминов
со стандартом ISO/IEC 15939 [45], которые в основном являются
определениями ИСО по метрологии [46].
Модель внутренних и внешних характеристик качества ПС,
согласно ISO/IEC 9126 и ISO/IEC 25000, состоит из шести групп
базовых показателей, каждая из которых детализирована следующими нормативными подхарактеристиками (рис. 30).
1. Функциональность (functionality). Способность ПС в определенных условиях решать задачи, нужные пользователям.
Определяет, что именно делает ПС, какие задачи оно решает.
Функциональность декомпозируется на следующую совокупность подхарактеристик:
1.1) функциональная пригодность (suitability) – способность
решать нужный набор задач;
1.2) точность (accuracy) – способность выдавать нужные результаты;
1.3) способность к взаимодействию (interoperability) – способность взаимодействовать с другими системами;
1.4) защищенность (security) – способность предотвращать
неавторизированный и неразрешенный доступ к данным и программам;
1.5) соответствие стандартам и правилам (compliance). Соответствие ПС имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам, определяющим функциональность.
2. Надежность (reliability). Способность ПС поддерживать
определенную работоспособность в заданных условиях. Надежность декомпозируется на следующую совокупность подхарактеристик:
2.1) зрелость, завершенность (maturity) – величина, обратная
частоте отказов ПС;
2.2) устойчивость к отказам (fault tolerance) – способность
поддерживать заданный уровень работоспособности при отказах
и нарушениях правил взаимодействия с окружением;
57
58
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Å
ƹ½¾¿ÆÇÊËÁ
ªÈÇÊǺÆÇÊËÕ
ûÇÊÊ˹ÆǻľÆÁ×
¬ÊËÇÂÐÁ»ÇÊËÕ
ÃÇËùÀ¹Å
¹»¾ÉѾÆÆÇÊËÕ
¦¹½¾¿ÆÇÊËÕ
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Å
̽ǺÊË»¹
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
¨ÉÁ»Ä¾Ã¹Ë¾ÄÕÆÇÊËÕ
¬½ÇºÊË»ÇɹºÇËÔ
¬½ÇºÊË»ÇǺÌоÆÁØ
¨ÇÆØËÆÇÊËÕ
¬½ÇºÊË»Ç
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
¬½ÇºÊË»Ç
ÊÇÈÉǻǿ½¾ÆÁØ
¨¾É¾ÆÇÊÁÅÇÊËÕ
™Æ¹ÄÁÀÁÉ̾ÅÇÊËÕ
™½¹ÈËÁÉ̾ÅÇÊËÕ
¬½ÇºÊ˻ǻƾʾÆÁØ
¬½ÇºÊË»ÇÌÊ˹ÆÇ»ÃÁ
ÁÀžƾÆÁÂ
ªÈÇÊǺÆÇÊËÕ
¶Í;ÃËÁ»ÆÇÊËÕ
ªË¹ºÁÄÕÆÇÊËÕ
ÃÊÇÊÌÒ¾Ê˻ǻ¹ÆÁ×
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
ɾÊÌÉÊÇ»
¬½ÇºÊË»ÇÈÉÇ»¾ÉÃÁ
¬½ÇºÊË»ÇÀ¹Å¾ÆÔ
ªÇÇË»¾ËÊË»Á¾
ªÇÇË»¾ËÊË»Á¾
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Å
Ê˹ƽ¹É˹Å
Ê˹ƽ¹É˹Å
ÈÉÇÁÀ»Ç½Á˾ÄÕÆÇÊËÁ
̽ǺÊË»¹
ȾɾÆÇÊÁÅÇÊËÁ
ÊÇÈÉǻǿ½¾ÆÁØ
›É¾Å¾ÆƹØ
ÖÍ;ÃËÁ»ÆÇÊËÕ
¶Í;ÃËÁ»ÆÇÊËÕ
Рис. 30. Внутренняя и внешняя модели качества согласно ISO/IEC 9126 и ISO/IEC 25000
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Ũ§
¹ÒÁÒ¾ÆÆÇÊËÕ
ªÈÇÊǺÆÇÊËÕ
ûÀ¹ÁÅǽ¾ÂÊË»Á×
«ÇÐÆÇÊËÕ
­ÌÆÃÏÁÇƹÄÕƹØ
ÈÉÁ¼Ç½ÆÇÊËÕ
­ÌÆÃÏÁÇƹÄÕÆÇÊËÕ
›ÆÌËɾÆƾ¾Á
»Æ¾Ñƾ¾
ùоÊË»Ç
2.3) способность к восстановлению (recoverability) – способность восстанавливать определенный уровень работоспособности
и целостность данных после отказа, с учетом необходимых для
этого времени и ресурсов;
2.4) соответствие
стандартам
надежности
(reliability
compliance).
3. Удобство использования (usability), или практичность.
Способность ПС быть удобным в обучении и использовании, а
также привлекательным для пользователей. Удобство использования декомпозируется на следующую совокупность подхарактеристик:
3.1) понятность (understandability) – показатель, обратный
усилиям, затрачиваемым пользователями, чтобы воспринять
набор понятий, на которых основано ПС, и их применимость для
решения своих задач;
3.2) удобство обучения (learnability) – показатель, обратный
усилиям, затрачиваемым пользователями, чтобы научиться работе с ПС;
3.3) удобство работы (operability) – показатель, обратный усилиям, предпринимаемым пользователями, чтобы решать свои
задачи с помощью ПС;
3.4) привлекательность (attractiveness) – способность ПС быть
привлекательным для пользователей;
3.5) соответствие
стандартам
удобства
использования
(usability compliance).
4. Производительность (efficiency), или эффективность. Способность ПС обеспечивать необходимую работоспособность по
отношению к выделяемым для этого ресурсам при заданных
условиях. Можно определить ее и как отношение получаемых с
помощью ПС результатов к затрачиваемым на это ресурсам. Эффективность декомпозируется на следующую совокупность подхарактеристик:
4.1) временная эффективность (time behaviour) – способность
ПС выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время;
4.2) эффективность
использования
ресурсов
(resource
utilisation) – способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная
память, сетевые соединения, устройства ввода и вывода и др.;
59
4.3) соответствие стандартам производительности (efficiency
compliance).
5. Удобство сопровождения (maintainability). Удобство проведения всех видов деятельности, связанных с сопровождением
ПС. Удобство сопровождения декомпозируется на следующую
совокупность подхарактеристик:
5.1) анализируемость (analyzability), или удобство проведения анализа, – удобство проведения анализа ошибок, дефектов и
недостатков, а также удобство анализа на предмет необходимых
изменений и их возможных эффектов;
5.2) удобство внесения изменений (changeability) – показатель, обратный трудозатратам на проведение необходимых изменений;
5.3) стабильность (stability) – показатель, обратный риску
возникновения неожиданных эффектов при внесении необходимых изменений;
5.4) удобство проверки (testability) – показатель, обратный
трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным эффектам;
5.5) соответствие стандартам удобства сопровождения
(maintainability compliance).
6. Переносимость (portability). Способность ПС сохранять
работоспособность при переносе из одного окружения в другое,
включая организационные, аппаратные и программные аспекты
окружения. Переносимость декомпозируется на следующую совокупность подхарактеристик:
6.1) адаптируемость (adaptability) – способность ПС приспосабливаться к различным окружениям без проведения для этого
специальных действий, исключая заранее предусмотренные;
6.2) удобство установки (installability) – способность ПС быть
установленным или развернутым в определенном окружении;
6.3) способность к сосуществованию (coexistence) – способность ПС сосуществовать с другими ПС в общем окружении, разделяя с ними ресурсы;
6.4) удобство замены (replaceability) другого ПО данным – способность данного ПС выступать вместо другого ПС, для решения
тех же самых задач, в заданном окружении;
6.5) соответствие стандартам переносимости (portability
compliance).
60
£¹Ð¾ÊË»Ç
»ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
¶Í;ÃËÁ»ÆÇÊËÕ
¨ÉǽÌÃËÁ»ÆÇÊËÕ
š¾ÀÇȹÊÆÇÊËÕ
¬½Ç»Ä¾Ë»ÇɾÆÁ¾
ÈÇÄÕÀÇ»¹Ë¾Ä¾Â
Рис. 31. Модель качества в использовании согласно ISO/IEC 9126 и
ISO/IEC 25000
Перечисленные атрибуты относятся к внутреннему и внешнему качеству ПС. Для описания качества ПС в использовании
стандарты предлагают другой, более узкий набор характеристик
(рис. 31):
1) эффективность (effectiveness) – способность ПС предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте;
2) продуктивность (productivity) – способность ПС предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов;
3) безопасность (safety) – способность ПС обеспечивать необходимо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде;
4) удовлетворение пользователей (satisfaction) – способность
ПС приносить удовлетворение пользователям при использовании в заданном контексте.
Стандарт ISO/IEC 9126-1-4 широко распространен, и многие
фирмы-разработчики используют его для описания, оценивания
и управления качеством ПС [47–51]. Начинается опытное освоение стандарта ISO/IEC 25000:2005.
2.1.7. Сравнительный анализ существующих моделей качества
Сравнительный анализ описанных моделей качества приведен в табл. 4. Всем этим моделям характерна иерархическая,
древовидная структура, состоящая из высокоуровневых показателей, которые детализируются показателями более низких
уровней, пока декомпозиция не приводит к атомарным и измеримым атрибутам (метрикам). Несмотря на различную терминологию, несложно идентифицировать эквивалентные составляющие моделей. В различных моделях количество уровней иерархии и число показателей и атрибутов разнятся и могут быть как
ограниченными, так и неограниченными.
61
Таблица 4
Сравнение структур моделей качества
Модель качества
Виды элементов модели /
количество уровней
Количество элементов Определены
на каждом уровне
ли метрики
Дж. МакКола
Факторы / 2
На 1-м уровне – 3,
на 2-м уровне – 11
Критерии / 1
23
Метрики / 1
Выбирается пользователями
Характеристики высокого уровня / 2
9
Б. Боема
Элементарные характе- 15
ристики / 1
FURPS
GQM
Метрики / 1
Выбирается пользователями
Атрибуты качества / 2
На 1-м уровне – 5,
на 2-м уровне – 27
Метрики / 1
Выбирается пользователями
Цели / 1
Выбирается пользователями
Вопросы / 1
Нет
Нет
Нет
Нет
Метрики / 1
Т. Гилба
Высокоуровневые
атрибуты / выбирается
пользователями
Выбирается пользователями
Низкоуровневые
атрибуты / выбирается
пользователями
Нет
Метрики / выбирается
пользователями
Р. Дроми
Высокоуровневые
атрибуты / выбирается
пользователями
Атрибуты, влияющие
на качество / выбирается пользователями
Компоненты / выбирается пользователями
62
Выбирается пользователями
Нет
Окончание табл. 4
Модель качества
Виды элементов модели /
количество уровней
Количество элементов Определены
на каждом уровне
ли метрики
SQUID
Характеристики качества / выбирается
пользователями
Выбирается пользователями
Нет
Атрибуты качества / 1
Метрики / 1
IEEE 1061
Факторы / выбирается
пользователями
Выбирается пользователями
Подфакторы / выбирается пользователями
Нет
Метрики / выбирается
пользователями
ГОСТ
28195
Группы (факторы) / 1
6
Комплексные показате- 19
ли (критерии) / 1
Метрики / 1
Выбирается пользователями, регламентирован набор
стандартных
Да, не
жестко
Оценочные элементы / 1 Выбирается пользователями, регламентирован набор
стандартных
ИСО / МЭК
Р 9126,
ISO / IEC
9126,
ISO / IEC
25000
Характеристики / 1
6
Подхарактеристики / 1
27
Атрибуты качества /
выбирается пользователями
Выбирается пользователями
Метрики / 1
Выбирается пользователями, регламентирован набор
стандартных
Да, не
жестко
Модели качества разрабатывались как основа для оценивания
качества, поэтому имеют в своем составе, помимо концептуальных элементов – показателей различных уровней, еще и измеримые – метрики. Более ранние модели по своей природе были, ско63
рее, качественными, нежели количественными, ввиду недостатка знаний о метриках. Более поздние предлагают более строгий
подход к оценке и измерению качества [52, 53]. Основной вектор
развития моделей качества определяется попытками сделать все
атрибуты качества измеримыми, а также стремлением разнести
на разные уровни качественные и количественные атрибуты.
2.2. Построение моделей качества
Помимо собственно устройства моделей, важно понимать процесс их построения.
2.2.1. Жесткие и гибкие модели
В соответствии с подходом или стандартом, модель качества
может быть как жесткой, т. е. строго фиксированной, с неизменным набором показателей и связями между ними, так и гибкой,
т. е. построенной для некоторого проекта в соответствии с пониманием заказчиков, пользователей и разработчиков [52].
Жесткий подход
При жестком подходе готовая модель качества используется в
качестве основы для оценивания любого проекта или ПС. Предполагается, что начальный каталог содержит все необходимые
показатели и для оценивания конкретного ПС необходимо выбрать из этого множества какую-либо часть. Примерами такого
подхода являются модели Боема, МакКола и FURPS.
Преимуществом жесткого подхода необходимо назвать то, что
подобные модели предлагают обобщенный, сравнимый взгляд на
качество потенциально различных ПС. Однако этот подход имеет и недостатки:
– отсутствие гибкости и расчет на то, что все показатели, необходимые для оценивания качества конкретного ПС, являются
подмножеством показателей модели. Это противоречит реальности [35], так как, несмотря на универсальность некоторых показателей, другие сильно зависят от вида ПС;
– сложность выделения и различения показателей качества,
которые приводят к частичному совпадению критериев, связанных с разными факторами.
Гибкий подход
Данный подход предполагает возможность создания собственной модели качества. В качестве показателей можно ис64
пользовать показатели существующих моделей или определять
свои. Никаких ограничений на количество уровней иерархии и
взаимосвязи показателей не накладывается. Примерами такого
подхода являются модели GQM, Гилба и метод SQUID.
Достоинством этого подхода следует считать возможность
максимально полно учесть особенности проекта. Также гибкая
модель может более качественно оценивать ПС за счет более детальной проработки показателей нижних уровней. Недостатками подхода являются дополнительные затраты на разработку
модели для каждого проекта и потенциально меньший уровень
корректности, так как за ее создание отвечают локальные для
проекта группы специалистов.
Смешанный подход
Некоторые исследователи пытаются использовать достоинства
обоих подходов. Так, в работе [54] описана модель ADEQUATE, в
которой фиксируется семь ключевых факторов, описывающих
качество с глобальной, общей для любых проектов точки зрения,
которые могут быть дополнены локальными факторами, учитывающими особенности конкретного проекта.
Модель, введенную стандартами ISO/IEC 9126 и ISO/IEC
25000, также можно отнести к этому подходу. Существуют примеры использования этой модели [47], в которых применяется
часть показателей верхнего уровня из модели стандарта и вводятся собственные показатели нижнего уровня, отражающие
специфику проекта.
2.2.2. Модели с совмещениями уровней и без
В ранних моделях качества, например, Боема или МакКола, можно обнаружить возможность наличия более одной связи от критерия к факторам, что порождало не древовидную,
а сетевую структуру иерархии показателей качества. Такого
рода ситуация носит название совмещения показателей. Многие авторы отмечают естественность этого явления, причины
которого определяются природой самих ПС [55]. Примерами
моделей, допускающих совмещение, являются модели МакКола и Боема. Примером модели без совмещений является модель
FURPS. Модель стандартов ISO/IEC 9126 и ISO/IEC 25000 следует считать смешанной, так как она не допускает совмещения
показателей на верхних уровнях и допускает совмещение на
нижних.
65
2.2.3. Внутренние и внешние свойства качества
Многие модели качества не делают явных различий между
внешними показателями, доступными пользователям, и внутренними, определяющими структуру и поведение ПС с точки
зрения разработки. Такие показатели сосуществуют в одной
модели и образуют одно множество показателей того или иного
уровня. Существуют подходы, в которых используется явное
различие между внутренними и внешними свойствами [55–58].
Пример важности такого рода различия можно найти в работе
[41], где процесс разработки, учитываемый с помощью внутренних показателей, управляется значениями внешних показателей. Другим примером являются модели качества стандартов
ISO/IEC 9126:2001-4 и ISO/IEC 25000:2005 – внешние, внутренние и использования.
2.3. Взаимосвязи между показателями качества
При построении модели качества целесообразно учитывать
взаимосвязи между одноуровневыми составляющими модели.
В табл. 5 показан пример такого учета [59] с использованием взаимосвязей типа «обратно пропорционален», «прямо пропорционален», «нейтрален».
Таблица 5
Корректность
Надежность
Эффективность
Целостность
Удобство использования
Сопровождаемость
Тестируемость
66
+
+ +
+ +
+ +
–
–
–
–
+
+
+ +
Способность
к взаимодействию
Повторное использование
Гибкость
Переносимость
Тестируемость
Сопровождаемость
Целостность
Эффективность
Надежность
Корректность
Фактор
Удобство использования
Взаимосвязь показателей качества согласно В. Пери
Окончание табл. 5
Гибкость
Переносимость
Повторное использование
Способность к взаимодействию
+ +
–
–
–
–
–
–
–
+ +
+
+
+
+
+ + +
+
Примечание: «+» – «прямо пропорционален»; «–» – «обратно пропорционален»; пустая ячейка – не оказывает влияния.
Пример из стандарта IEEE 1061-92 приведен в табл. 6.
Таблица 6
O
X O
O
Расширяемость
O
Верифицируемость
O
Удобство использования
X
Повторное использование
O
Корректность
O
Живучесть
Надежность
Способность
к взаимодействию
Сопровождаемость
O
Целостность
Переносимость
Эффективность
Гибкость
Целостность
Способность к взаимодействию
Сопровождаемость
Переносимость
Надежность
Живучесть
Корректность
Повторное использование
Верифицируемость
Удобство использования
Расширяемость
Гибкость
Фактор
Эффективность
Взаимосвязь факторов качества по IEEE 1061
X
X
X O X
X O
X
X
X X X
O
X
X
X
X
O
O
O
O
X
O
O
O
X
O
X
O
Примечание: X – конфликт между факторами; O – факторы поддерживают
друг друга; пустая ячейка – отсутствие взаимоотношений.
67
Дальнейшие исследования характеризуются более детальным
описанием типов взаимосвязей показателей качества. Так, в работах [60, 61] используются типы «Реализует», «Разрушает»,
«Поддерживает», «Нарушает» и «Неизвестно», «Эквивалентно», «Скорее поддерживает», «Скорее нарушает».
В работах [54, 62] используются карты взаимосвязи показателей для идентификации конфликта между показателями качества.
2.3.1. Методы построения моделей качества
Одним из основных недостатков рассмотренных подходов является отсутствие четко определенной методики построения моделей качества. Только отдельные работы определяют основные
шаги построения таких моделей.
В работе [32] содержатся следующие рекомендации:
– определить множество показателей, которые являются важными для ПС, при этом множество показателей должно обладать
свойством полноты, а элементы этого множества не должны совмещаться;
– найти метрики, позволяющие судить о том, в какой степени
ПС реализует эти показатели;
– исследовать показатели и связанные с ними метрики с целью определения их корреляции с качеством ПС, потенциальную измеримость, используемость и автоматизацию расчетов;
– оценить каждую метрику на предмет существования зависимостей, пересечений и потенциальных дефектов;
– на основе двух предыдущих шагов скорректировать наборы
показателей и метрик.
В работе [40] приводятся следующие шаги построения тестируемой, измеримой и детализируемой модели качества:
– определить показатели качества верхнего уровня;
– определить состав компонентов ПС;
– классифицировать наиболее важные и ощутимые свойства
каждого компонента;
– разработать набор аксиом для связывания свойств компонента с показателями качества;
– оценить полученную модель, выявить ее недостатки, при
необходимости переработать.
Очевидно, что, с формальной точки зрения, оба предложенных подхода к построению модели качества не могут претендо68
вать на статус метода, они лишь очерчивают основные шаги, необходимые для построения модели качества.
2.3.2. Анализ вариантов построения моделей качества
Сравнительная сводка конструктивных аспектов моделей качества содержится в табл. 7.
Таблица 7
Сравнение построений моделей качества
Модель
качества
Способ построения
Дж. МакКола
Жесткий
Б. Боема
Вид отношений
между элементами
Иерархический
Иерархический, зависиЖесткий
мости между
метриками
FURPS
Жесткий
Иерархический
GQM
Гибкий
Иерархический
Т. Гилба
Гибкий
Иерархический
Р. Дроми
Гибкий
SQUID
Гибкий
Определен ли метод
построения / есть ли
разделение на внешОбъекты
ние и внутренние
оценивания
элементы / можно ли
совмещать уровни
Нет / нет / да
Да / нет / да
Нет / нет / нет
Критерии
Элементарные
характеристики
Атрибуты
качества
нижнего
уровня
иерархии
Да / нет / да – на
Вопросы
нижних элементах
Высоко- и
низкоНет / нет / да
уровневые
атрибуты
Связи между
компонентами
и высокоДа / да / да
уровневыми
атрибутами
качества
Иерархический, связи
между внутНет / да / да
ренними и
внешними
атрибутами
–
Атрибуты
качества
69
Окончание табл. 7
Модель
качества
Способ построения
IEEE 1061 Гибкий
Вид отношений
между элементами
Определен ли метод
построения / есть ли
разделение на внешОбъекты
ние и внутренние
оценивания
элементы / можно ли
совмещать уровни
Иерархический, конфликтные и
поддерживаю- Да / нет / да
щие отношения между
факторами
Элементы
любого
уровня
ГОСТ
28195
Смешан- Иерархиченый
ский
КомплексДа / нет / да – на
ные понижних элементах казатели
(критерии)
ИСО /
МЭК Р
9126,
ISO / IEC
9126,
ISO / IEC
25000
Смешан- Иерархиченый
ский
Да / да / да – на
Атрибуты
нижних элементах качества
Существующие подходы к построению моделей качества не
основаны на строгих формальных принципах. Вместе с тем на
основе их анализа можно выявить ряд аспектов, играющих важную роль в процессе построения моделей качества:
– необходимость формализации связей показателей верхнего
и нижнего уровней в иерархической структуре модели качества;
– важность возможности существования проекций модели
качества – с точки зрения пользователей и с точки зрения разработчиков;
– существование зависимостей между показателями качества
на одном уровне, которые необходимо выявить;
– необходимость в классификации показателей качества на
внешние и внутренние для повышения применимости модели;
– необходимость допущения совмещения показателей, в силу
того, что они могут различными способами затрагивать разные
свойства ПС;
70
– необходимость допущения существования связей между метриками и показателями не только нижнего уровня, таким образом, чтобы показатели верхнего или промежуточных уровней
могли оцениваться или группой метрик, или некоторыми непосредственно вычисляемыми метриками.
2.4. Адаптация моделей качества
В основном адаптация моделей и стандартов заключается в
выборе показателей качества и определении их взаимосвязей.
Номенклатура показателей качества и связи между этими показателями составляют модель качества. Не все модели и стандарты допускают адаптацию, некоторые делают это не в полной
мере.
Тщательное и корректное определение, выбор номенклатуры
и оценивание стандартизированных характеристик качества ПС
существенно, а иногда критически влияет на последующее качество функционирования информационных систем. Типовой
набор характеристик, подхарактеристик и атрибутов качества
комплексов программ, представленный в базовых стандартах,
используется как исходные данные и шаблоны при подготовке
технических заданий и спецификаций требований к качеству
ПС. Корректировка состава и значений параметров позволяет
уточнять и адаптировать этот набор характеристик ПС для конкретных проектов и потребителей и сокращать дефекты, возникающие вследствие неоднозначности и некорректности описаний требований к качеству. Методы стандартизированного
оценивания и измерения различных характеристик качества используют при подготовке конкретных методик испытаний качества проектов ПС. Целенаправленный выбор и оценивание стандартизированных характеристик применяется как основа для
сравнения качества программных средств разных поставщиков
и выявления среди них более предпочтительных.
Проблеме выбора номенклатуры показателей качества за последние 20 лет было посвящено много теоретических исследований [32], однако их практическое применение затруднительно, так как требует чрезвычайно сложных методик оценивания
показателей качества, что делает сертификацию программных
продуктов слишком дорогостоящей, либо вообще практически
не реализуемой. В то же время недостаточно полная система показателей качества плохо описывает характеризуемое программ71
ное средство, что может привести к несоответствию построенной
модели качества реальному программному средству.
Нацеленность показателей свойств программ на ранжирование программ по заданному критерию качества обуславливает
ряд требований, предъявляемых к этим показателям [64]:
– малая трудоемкость вычислений;
– воспроизводимость результата измерений;
– адекватность измеряемому свойству программы (т. е. хорошая корреляция показателя со сложившимся в среде программистов интуитивным представлением о степени предпочтения
одних программ перед другими по данному критерию качества).
Исходными данными и высшим приоритетом при выборе показателей качества в большинстве случаев являются назначение,
функции и функциональная пригодность соответствующего программного средства. Достаточно полное и корректное описание
этих свойств должно служить базой для определения значений
большинства остальных характеристик качества. Принципиальные возможности и точность измерения значений характеристик
качества всегда ограничены в соответствии с их содержанием.
Это определяет рациональные диапазоны значений каждой характеристики, которые могут быть выбраны на основе здравого
смысла, а также путем анализа прецедентов в спецификациях
требований реальных проектов [66].
2.5. Области применения моделей качества
Модели качества служат для оценивания ПС. Тем не менее их
роль на разных этапах ЖЦ ПС бывает различной. Не претендуя
на полноту, представим основные аспекты использования моделей качества на разных этапах ЖЦ ПС.
2.5.1. Использование моделей качества
для описания требований к ПС
Обычно модели качества используются для описания нефункциональных требований (таких как эффективность, безопасность и т. п.). Некоторые авторы [40, 41, 66] вводят специальную
семантику использования моделей качества на этапе анализа
требований к ПС.
В работе [57] модели качества используются для оценивания
требований в процессе их анализа. Согласно этому подходу, происходит оценивание таких артефактов, как множество требований, частные требования, ограничения, переменные, константы
72
и отношения. Для частных требований оцениваются их соответствие семи свойствам поддержки качества (полнота, точность,
согласованность, проверяемость, трассируемость, определенность и неизбыточность). Результирующая модель качества может модифицироваться для учета новых требований, может быть
адаптирована для применения в других проектах.
В работах [41, 66] модель качества используется как базис и
инструмент для определения требований к ПС. Согласно [66],
благодаря использованию моделей качества в процессе анализа
требований достигаются следующие преимущества:
– все важные типы требований качества разрабатываются на
основе модели, что увеличивает степень полноты множества требований;
– требования качества упорядочиваются в виде иерархии показателей, что увеличивает степень возможности их анализа;
– согласование между заказчиками, пользователями и разработчиками упрощается благодаря использованию согласованной
терминологии показателей модели качества.
2.5.2. Использование моделей качества
для проектирования архитектуры ПС
В работах [50, 66–69] модели качества используются в процессе разработки архитектуры ПС.
В работе [67] показатели качества используются для определения архитектурных шаблонов. Показано, каким образом можно использовать модель качества для выбора архитектурного
шаблона исходя из требуемых качественных свойств (таких как
производительность, безопасность или надежность). Данные
свойства качества представлены посредством трех категорий:
– внешние стимулы – события, в результате которых архитектура может претерпеть изменения;
– архитектурные решения – составляющие архитектуры
(компоненты, коннекторы и их свойства), которые имеют непосредственное влияние на достижение целевого качественного
свойства;
– реакции – измеримые (или наблюдаемые) качественные
свойства, используемые для оценивания степени соответствия
архитектуры требованиям к качеству.
Используя данный подход, архитектор ПС может определить
отношения между архитектурными решениями и целевыми показателями качества.
73
Метод анализа с целью выбора компромиссного решения,
основанный на атрибутах, использует структуры, называемые
деревьями услуг [69]. Деревья услуг используются для представления требований заказчика к качеству в терминах показателей
качества. После создания такого рода представления анализируется семейство архитектур, которые соответствуют полученным
показателям качества. На этом этапе используется метод [67],
определяющий множество шаблонных архитектурных решений.
Затем с учетом контекста разработки и проектных рисков происходит выбор подходящего архитектурного шаблона.
В работе [50] описан похожий метод, вместо деревьев услуг
для анализа полноты архитектуры, с точки зрения качества, используются модели качества из ISO/IEC 9126:2001-4.
В работе [68] ограниченная иерархия показателей качества
используется для определения последствий выбора того или иного архитектурного решения. Авторы определяют множество конфликтов между показателями качества и предлагают методику
анализа с целью выбора компромиссного решения по архитектурному дизайну для будущих проектов.
2.5.3. Использование моделей качества
для реализации ПС
На этапе реализации качество ПС находится в сильной зависимости от используемого языка программирования. Эффект от
используемого языка может быть положительным, отрицательным или нейтральным. Большая часть существующих языков
оказывает или нейтральное, или негативное влияние на качество
ПС. В работах [40, 55] вводится модель качества, служащая для
оценивания языков программирования. Основные конструкции
языка программирования разбиваются на два подмножества –
подмножество конструкций, описывающих артефакты (переменные, константы и типы), и подмножество конструкций, описывающих вычисления (циклы, условные операторы, выражения и
т. п.). В качестве показателей верхнего уровня используется подмножество характеристик из ISO/IEC 9126:2001-4, дополненное
характеристикой «Зрелость процесса» с подхарактеристиками
«Ориентирован на клиента», «Строго описан», «Гарантирован»
и «Эффективен».
В работе [41] модели качества используются для определения целей процесса разработки. Эти цели описаны как требова74
ния к качеству в терминах внешних измеримых качественных
свойств. Цели определяются путем задания значений внешним
свойствам, а внешние свойства отображаются на внутренние.
Разрабатываемая ПС подлежит постоянной проверке на соответствие определенным целям.
В работе [70] модели качества также используются для оценивания ПС в период его ЖЦ. Метод состоит из трех фаз: спецификация, применение и упаковка. Модель качества разрабатывается на фазе спецификации с использованием GQM. В дальнейшем
эта модель используется для оценивания специфичных нефункциональных требований на фазе применения. Фаза упаковки
служит для аккумулирования опыта, полученного в данном проекте, и фиксации его в модели качества в целях ее улучшения и
повторного использования.
2.5.4. Использование моделей качества
при приобретении ПС
В процессе приобретения встает проблема выбора одной из
множества функционально эквивалентных ПС. Как правило,
с этой целью используются сравнительные таблицы, проектирующие семейства ПС на множества свойств. Альтернативой
применения таблиц является применение моделей качества для
сравнения семейства ПС. В отличие от таблиц, модели качества
предоставляют более достоверную основу для сравнения.
В работе [71] использованы модели качества стандарта
ISO/IEC 9126:2001-4 для описания критериев и метрик оценивания, использующихся для сравнения компонент ПС. В дополнение к требованиям качества (функциональным и нефункциональным) добавлены характеристики «Бизнес-отношения»
(«Цены», «Надежность фирмы-разработчика» и т. п.), а также
определены характеристики, относящиеся к типам ПС («Операционные системы», «Механизмы коммуникации» и т. п.).
В работах [47, 49] описан опыт использования моделей качества для оценивания веб-порталов. Подход основан на применении стандарта ISO/IEC 9126:2001-4 в качестве основы для
разработки моделей качества. Путем снабжения некоторых
качественных свойств весовыми коэффициентами и последующего оценивания авторам удается ранжировать, сравнивать и
выбирать лучшее с определенной точки зрения программное решение.
75
2.5.5. Использование моделей качества
при сертификации ПС
Одним из главных вопросов сертификации ПС является выбор множества критериев. В работе [72] предлагаются иерархические модели для описания критериев сертификации разных
видов ПС, которые, по сути, являются моделями качества. При
разработке моделей качества рассматриваются несколько уровней:
– уровень сертификации – критерии описания экономических показателей разработки;
– агент сертификации – заинтересованные в процессе сертификации стороны (разработчики, аналитики и т. п.);
– фокус критериев сертификации – функции ПС, концепция
ПС, контекст;
– цель сертификации – стоимость, пригодность, удобство работы, соответствие.
2.5.6. Использование моделей качества
при идентификации рисков
В работе [38] модели качества используются как основа для
выявления рисков проектов NASA. Риски ассоциируются с качественными свойствами модели. Конкретные качественные свойства идентифицируются посредством их влияния на качество
уже реализованных проектов и возможностью их количественного оценивания. В последующем они используются для вывода
множества метрик, в зависимости от ПС и процесса разработки.
Согласно авторам, для того, чтобы модель качества могла быть
использована в управлении рисками, необходимо наличие у нее
следующих свойств:
– возможность количественного оценивания рисков (например, число и степень значимости ошибок);
– возможность общего оценивания рисков проекта (возможность за счет метрик измерить общую величину рисков).
2.5.7. Другие применения моделей качества ПС
В дополнение к примерам использования моделей качества,
связанных с каким-либо этапом ЖЦ, существуют и другие примеры. В работе [72] с помощью сбора мнений пользователей,
разработчиков и менеджеров в соответствии с моделью качества
стандарта ISO/IEC 9126:2001-4 и применением метода, соотносящего производительность с экономическим, социальным и
76
техническим измерениями, авторами удается получить числовой фактор качества, используемый менеджерами для принятия
экономических решений, в соответствии с производительностью
ресурсов процессов разработки ПС.
В работе [73] на основе ISO/IEC 9126:2001-4 определена модель качества, используемая как основа для оценивания информации, предоставляемой о ПС компаниями-разработчиками.
С помощью анализа эксплуатационной документации авторы
пытаются оценить набор показателей качества из модели качества и определяют часть компонентов, для которых показатели
качества должны быть оценены на основе данных, содержащихся непосредственно в них. Путем анализа полученной информации авторы определяют существование или отсутствие пробелов
между описаниями и реальными компонентами ПС.
2.5.8. Анализ вариантов использования
моделей качества
Некоторые рассматриваемые подходы, конкретно – [40, 41],
относятся более чем к одному этапу, направлены на поддержку
всего процесса разработки. Остальные подходы обслуживают
определенный этап ЖЦ ПС.
Интересным выводом обзора применения моделей качества
может послужить следующее наблюдение. Несмотря на то, что
главная задача разработки моделей качества состоит в представлении знаний о показателях для оценивания готового ПС, неменьший объем применений модели качества находят на ранних
этапах разработки, от анализа требований до реализации, когда
готовое ПС не существует. Этот факт свидетельствует о важности начальных этапов разработки, необходимости привлечения
на них формальных методик. Также это свидетельствует о важности использования моделей качества для всех сторон процесса
изготовления ПС – разработчиков, заказчиков и пользователей.
2.6. Классификация моделей качества
В настоящий момент известны несколько классификаций моделей качества. Как правило, основными критериями классификации являются структура, способы разработки и варианты применения моделей качества.
Модели качества в основном классифицируются на основе
данных о структуре, к которым относятся количество уровней
77
иерархии (так, появляются классы моделей с двумя [40, 74] и тремя уровнями иерархии [26–29]) и количество отношений между
элементами первых двух уровней (1:N в [26–29], N:M в [74]).
В работе [70] в качестве показателей классификации выбраны данные о способах разработки модели качества – жесткая
или гибкая. Гибкий способ разработки модели в дальнейшем
разделяется на явный, т. е. разрабатываемый непосредственно
пользователем модели (как, например, в работах [35, 75]), или
неявный, т. е. получаемый посредством некоторого вывода с помощью автоматизированных средств, применения математических методов и методик искусственного интеллекта (как, например, в работах [76, 77]).
В работе [78] модели качества классифицируются по признаку использования, вводятся классы общих моделей и моделей,
ориентированных на продукт (специфические модели).
Общие модели описывают качество ПС по отношению к обобщенным тенденциям развития отрасли. В дальнейшем модели
этого класса разделяются на три категории:
1) глобальные модели, направленные на оценку обобщенного
качества ПС;
2) сегментированные модели, предлагающие инструменты
для оценивания качества ПС в зависимости от ее вида;
3) динамические модели, поддерживающие процесс оценивания качества для разных этапов ЖЦ ПС.
Модели, ориентированные на продукт, учитывают специфические для проекта создания ПС данные и, следовательно, позволяют оценить качество ПС более точно. Они подразделяются на
три категории:
1) заказные модели, которые экстраполируют историю создания ПС для оценивания качества;
2) модели, основанные на наблюдениях, которые оценивают
качество в соответствии с наблюдением за ходом проекта по созданию ПС;
3) модели предсказания качества, основанные на измерениях,
которые учитывают отношения между измерениями значений
метрик ПС и качеством и используют эти отношения для гарантии и улучшения качества ПС.
Согласно [78], общие модели позволяют оценить качество менее точно, основываясь на эмпирических данных индустрии ПС,
в то время как модели, ориентированные на продукт, позволяют
78
§ºÇºÒ¾ÆÆÔ¾
›É¾Å¾ÆÆÔ¾
ªÈ¾ÏÁÍÁÐÆÔ¾
œÁºÃÁ¾
¬ÊËÇÂÐÁ»Ô¾
ªÅ¾Ñ¹ÆÆÔ¾
Ÿ¾ÊËÃÁ¾
Рис. 32. Схема классификации моделей качества
производить оценку качества более точно, используя системы
измерений, зависящие от типа продукта. При этом общие модели имеют более широкое применение и их использование менее
затратно, так как не требуется создавать систему измерений для
каждого продукта.
Общие модели качества могут быть преобразованы в модели,
ориентированные на продукт, если есть возможность добавить
специфическую для ПС информацию к модели. Модели, ориентированные на продукт, могут быть обобщены для получения
общей модели, если существуют проверенные результаты применения этих моделей при оценке однотипных ПС.
На рис. 32 изображена схема классификации моделей качества, содержащая два измерения – специфичное/обобщенное,
устойчивое/временное.
2.6.1. Специфичное/обобщенное измерение
Это измерение посвящено раскрытию степени детализации
модели качества. Общие модели обычно являются менее сложными по своей структуре (имеют меньше уровней, свойств качества и отношений между ними), так как описывают качество с
обобщенных, абстрактных позиций, не учитывая специфические
для того или иного ПС свойства. Обычно общие модели строятся
с использованием жесткого подхода.
Специфические модели могут учитывать все детали конкретного проекта или ПС. Они создаются с использованием гибкого
подхода, имеют, как правило, более сложную структуру.
79
2.6.2. Устойчивое/временное измерение
Это измерение отражает степень повторного использования
модели качества. Модели с низким показателем повторного использования обычно создаются под конкретный проект или ПС
с использованием гибкого подхода создания моделей качества.
Они учитывают специфику проекта, и поэтому степень их повторного использования ниже.
Устойчивыми являются модели, разрабатываемые на том
уровне абстракции, на котором детали ПС становятся не существенными, могут характеризовать целые семейства ПС и создаются с помощью жесткого подхода к построению моделей качества.
Вместе с тем возможны и компромиссные варианты, связанные как с обобщением временных моделей до уровня устойчивых, так и с детализацией устойчивых до уровня временных.
Разные по степени повторного использования модели могут создаваться с использованием смешанного подхода к построению
моделей качества. Значения повторного использования в любом
случае будут обратно пропорционально зависеть от уровня детализации артефактов модели.
На практике одним из важных элементов развития модели
качества являются требования к ПС, которые управляют аспектами детализации этих моделей. В работе [79] описан итеративный подход к развитию и оценке требований к ПС посредством
разработки модели качества.
Основными характеристиками временных моделей качества
являются:
– разработка, управляемая требованиями. Разработка модели
качества осуществляется в том направлении, которое обусловлено необходимостью зафиксировать определенное требование к
ПС;
– вертикальная ориентация. Свойства качества ПС определяются с максимально возможным уровнем детализации с целью
предоставить наиболее точные данные измерений;
– разработка, инициируемая новым проектом. Как правило,
временные модели разрабатываются под конкретный проект
создания ПС, поэтому их разработка возобновляется для нового
проекта.
Характеристиками устойчивых моделей качества выступают:
80
ªÈ¾ÏÁÍÁÐÆÔ¾
§ºÇºÒ¾ÆÆÔ¾
›É¾Å¾ÆÆÔ¾
œÁºÃÁ¾
¥Ç½¾Ä՜Áĺ¹
(2.
*&&&
426*%
¥Ç½¾ÄÕ
ÉÇÅÁ
œ§ª«
œ§ª«©¡ª§¥¶£
*40 *&$
*40 *&$
ªÅ¾Ñ¹ÆÆÔ¾
¬ÊËÇÂÐÁ»Ô¾
'6314
¥Ç½¾ÄÕ¥¹Ã£ÇĹ
¥Ç½¾Ä՚ǾŹ
Ÿ¾ÊËÃÁ¾
Рис. 33. Классификация моделей качества
– разработка, управляемая индустриальными тенденциями.
В силу отсутствия ориентации на конкретный проект по созданию ПС, разработка устойчивых моделей ориентируется на охват
максимально общих свойств определенного вида ПС;
– горизонтальная ориентация. В устойчивых моделях определяются только верхние уровни иерархии показателей качества;
– разработка, возобновляемая новым типом ПС. При появлении нового типа ПС возникает необходимость определения показателей и отношений между ними для высокоуровневого описания качества этого типа ПС.
Помимо собственно повторного использования моделей качества, существует возможность повторного использования их отдельных структурных составляющих. Такие фрагменты моделей
качества являются шаблонами, объединяющими показатели и
отношения между ними, комбинируя которые, можно построить
новые модели качества.
На рис. 33 представлена классификация основных моделей
качества в выбранных измерениях.
2.7. Основные недостатки
существующих моделей качества
Общим недостатком существующих моделей качества является трудность инженерной интерпретации значений показателей,
81
которые эти модели вводят. Реализация этой интерпретации
возможна только за счет учета принципов проектирования, которые соотнесены с тем или иным способом реализации проекта, использованием определенных языков программирования и
т. п. Существующие модели качества не регламентируют четкое
соотнесение показателей качества и практик проектирования
в рамках определенной парадигмы, а именно принципы проектирования устанавливают для каждой парадигмы границы
качества. Иными словами, отсутствует формализация квантификации архитектурных решений. Например, модель качества
стандарта ISO/IEC 25000 не содержит информации о том, как
связаны принципы объектно-ориентированного проектирования, допустим такие, как высокая связность и низкое сцепление,
с показателями качества, например, с переносимостью или с тестируемостью. Отображения между показателями и свойствами
качественного дизайна содержатся в этой модели качества неявно. Отсюда происходит разрыв между тем, что измеряется, как
интерпретируется и какие преобразования ПС для улучшения
его качества можно было бы применить.
Таким образом, основными недостатками существующих моделей качества являются:
1) высокая степень специализации. Большая часть моделей
качества создавалась для оценивания конкретных проектов или
ПС, в интересах конкретных разработчиков ПС, что затрудняет
их развитие и расширение области использования;
2) отсутствие терминологической согласованности. Узкая
специализация моделей породила применение разных терминов
для описания эквивалентных явлений;
3) отсутствие методов обоснования процесса построения. Часто
модели качества строились по интуиции, хотя некоторые авторы
и приводили методики по построению моделей, для них отсутствовали формализация и технология поддержки этих методик;
4) уровень детализации обратно влияет на уровень применимости. Существующие модели являются или абстрактными, при
этом широко применимыми, или детальными и узкоприменимыми. При этом высокий уровень абстракции нивелирует широкое
применение, а узкая применимость нивелирует высокую степень
детализации;
5) низкая степень формализации. Отсутствует строгая математическая основа для описания формальных свойств моделей
82
и методик, их построения и способов адаптации, повторного использования;
6) отсутствие механизмов учета принципов проектирования.
Нет возможности оценивания соответствия принимаемых проектных решений зарекомендовавшим себя принципам проектирования в данной программной парадигме, что не дает возможности проследить причинно-следственную связь между качеством
ПС и принципами принятия проектных решений.
2.8. Требования к модели качества
Рассмотренным моделям свойственна определенная общность
в представлении качества, которая состоит в том, что понятие качества декомпозируется на ряд разноуровневых характеристик,
которые образуют иерархическую структуру, каждый уровень
иерархии которой определяет степень детализации представления понятия о качестве. Подхарактеристики, производные и
базовые метрики качества можно комбинировать между собой,
добиваясь все большего и большего обобщения свойств, формулирующих в целом представление о качестве объекта в иерархическом виде.
В настоящее время объем знаний, накопленных о качестве
программного обеспечения, достаточно велик. Задача построения формальной модели качества – это задача представления
этого знания в системном, структурированном, интуитивно понятном всем участникам, задействованным в процессе ЖЦ ПС,
пригодном для повторного использования, виде. Основными требованиями, предъявляемыми к модели качества, являются:
1) возможность описания качества в абстрактном, не зависимом от реализации виде;
2) необходимость формализации связей характеристик разных уровней в иерархической структуре модели качества;
3) наличие механизма по добавлению или удалению характеристик разного уровня и связей между ними;
4) однозначность толкования характеристик и подхарактеристик качества ПС;
5) возможность существования проекций модели качества, с
точки зрения основных участников создания ПС;
6) возможность существования зависимостей между одноуровневыми характеристиками качества;
83
7) возможность классификации характеристик качества, например, на внешние и внутренние для повышения применимости модели;
8) возможность совмещения характеристик, в силу того, что
они могут различными способами затрагивать разные свойства
ПС;
9) возможность существования связей между характеристиками не только смежных уровней иерархии;
10) возможность формальной проверки независимости листовых элементов модели;
11) возможность формальной проверки отсутствия в аналитических выражениях для характеристик и подхарактеристик зависимых компонентов;
12) существование механизма минимизации состава компонент, включаемых в выражения для характеристик и подхарактеристик;
13) существование механизма проверки наличия одинаково
выраженных характеристик и подхарактеристик;
14) необходимость учета принципов проектирования для возможности их дальнейшего оценивания и обеспечения причинноследственной связи между качеством ПС и принципами принятия проектных решений в той или иной парадигме;
15) необходимость в целом соответствовать всему положительному опыту, накопленному исследователями качества ПС,
стандартам и технологиям, применяемым в этой области.
2.9. Формальная модель качества
Формализация модели качества основывается на теории категорий. В качестве обоснования выбора именно этого формального аппарата выступают такие свойства теории категорий, как:
– возможность использования в качестве универсального
средства для описания различных концепций;
– применимость в качестве мощного средства абстракции и
обобщения;
– простота использования в качестве основы методологических принципов разработки от концепции к реализации;
– возможность построения с помощью теории категорий универсальных конструкций.
С целью унификации и согласованности описаний в данном разделе приводятся определения основных теоретико84
категорных понятий, и дальнейшее их использование в работе
будет соответствовать приведенному здесь контексту.
Категория С состоит из класса объектов Ob(C) и класса морфизмов Моr(С). Основные свойства категории:
1) Mor(С) = A, B∈Ob(C)HC(A, B), где HC(A, B) – непересекающиеся подмножества в Mor(C), A и B пробегают Ob(C);
2) для любых A, B, D ∈ Ob(C) определено отображение:
ABC: НC(A, B) × НC(B, D) → НC(A, D),
такое что:
– для любых α, β, Γ ∈ Mor(C); если определены (α, β) и (β, Γ),
то ((α,β),Γ) = (α, (β, Γ));
– для любого A ∈ Оb(C) найдется элемент 1A ∈ HC(A, A), такой,
что для любых α ∈ НC(A, B) и β ∈ НC(B, A) (B ∈ Оb(C)) имеют место
равенства
(1A, α) = α;
(β, 1A) = β.
Kласс Оb(C) называется классом объектов категории C, а класс
Моr(C) – классом морфизмов. Элемент ϕ множества НC(A, B) называется морфизмом из объекта A в объект B и обозначается
ϕ: A → B, или AϕB. Отображение ABD называется законом композиции. Элемент (α, β) мы будем обозначать через βα, или αβ
( α: A → B и β: B → D), и называть композицией последовательных морфизмов α и β. Морфизм 1A называется тождественным
морфизмом объекта A. Элементы множества НC(A, B) называются параллельными морфизмами. Мы часто будем писать Н(A, B)
вместо НC(A, B).
Определение 23. Морфизм α: A → B называется:
1) изоморфизмом, если найдется β ∈ Моr(C), такой, что
αβ = 1A, βα = 1B;
2) (ко)ретракцией, если выполнено βα = 1B (αβ = 1A);
3) моно(эпи)морфизмом, если для любых β, Γ ∈ Моr(C) выполняется βα = Γα ⇒ β = Γ (αβ = αΓ ⇒ β = Γ), если композиции
определены;
4) биморфизмом, если α – и моно, и эпиморфизм;
5) (ко)постоянным морфизмом, если для любых β, Γ ∈ Моr(С)
выполняется βα = Γα (αβ = αΓ), если композиции определены.
Определение 24. Категория C называется конкретной, если
она изоморфна подкатегории категории множеств Set. Поскольку последняя категория изоморфна подкатегории категории не85
пустых множеств Setn, категория C конкретна тогда и только
тогда, когда она изоморфна подкатегории категории Setn. Любая
подкатегория конкретной категории конкретна, и произведение
конкретных категорий является конкретной категорией.
Определение 25. Категория C называется полной, если в ней
каждая C-диаграмма имеет предел [81].
Определение 26. Категория C называется кополной, если каждая C-диаграмма имеет копредел [81].
Определение 27. Биполной называется категория, являющаяся одновременно полной и кополной [81].
Определение 28. Конечной диаграммой называется диаграмма, имеющая конечное число объектов и конечное число стрелок
между ними. Категория называется конечно полной, если она содержит предел любой конечной диаграммы. Конечная кополнота
и конечная биполнота определяются аналогичным образом [85].
Определение 29. Объекты A и B категории C называются связанными, если в C найдется такая конечная последовательность
объектов A0,A1,…,An что A=A0, B=An и H(Ai-1,Ai)∪ H(Ai,Ai+1)≠∅
для каждого i=0, 1,…,n-1. Категория C, в которой каждая пара
объектов связана, называется связанной [80].
Определение 30. Категория SubC называется подкатегорией
некоторой категории C, если:
а) каждый объект категории SubC является объектом категории C;
б) каждый морфизм категории SubC является морфизмом категории C;
в) единичные морфизмы категории SubC являются единичными морфизмами в C;
г) произведение αβ морфизмов α,β∈SubC совпадает с произведением этих же морфизмов в категории C. Подкатегория SubC категории C называется полной подкатегорией, если HSubC(A,B)=
= HC(A,B) для каждой упорядоченной пары объектов A,B ∈
SubC.
Определение 31. Множество морфизмов (αi: A→Ai, i∈I) произвольной категории C с общим началом в объекте A называется
конусом с вершиной A. Любое подмножество морфизмов конуса
называется подконусом. Двойственным к понятию конуса морфизмов является понятие коконуса морфизмов: коконус морфизмов есть множество морфизмов (αi: Ai→ A, i∈I) с общим концом
в объекте A.
86
Пусть (αi: Ai→B, i∈I) (2.1) – фиксированный коконус категории C. Конус (βi: X→Ai, i∈I) называется допустимым относительно коконуса (2.1), если βiαi = βjαj для всех i,j∈I (2.2).
Определение 32. Конус (σi: U→Ai, i∈I) называется универсальным относительно коконуса (2.1), если он допустим относительно этого коконуса и если для любого конуса (βi: X→Ai, i∈I), допустимого относительно коконуса (2.1), существует такой единственный морфизм ψ: X → U, что βi = σiψ, i∈I.
Универсальный конус (σi: U→Ai, i∈I) относительно коконуса
(αi: Ai→B, i∈I) будет обозначаться coun(αi, i∈I). Все конусы, универсальные относительно данного коконуса (αi, i∈I), составляют
подобъект семейства объектов Ai, который обозначается Coun(αi,
i∈I).
Двойственным образом определяется коуниверсальный коконус относительного некоторого конуса (βi: A→Bi, i∈I), который
будет обозначаться cocoun(βi, i∈I). Соответствующий факторобъект семейства объектов будет обозначаться Cocoun(βi, i∈I) [76].
Рассмотрим теперь частный случай, когда коконус (2.1) состоит из двух морфизмов αi: Ai→B, i=1,2. Если (U; σ1, σ2)=coun(αI,
α2), то в силу (2.2) имеет место коммутативный квадрат
6
"


(2.3)


"
#
и для любых морфизмов ϕ: X → A1 и ψ: X → A2, для которых
ϕαI = ψα2 существует такой единственный морфизм Γ: X → U, что
ϕ=Γσ1 и ψ=Γσ2. Коммутативный квадрат (2.3), обладающий указанным свойством, часто называют универсальным квадратом
относительно морфизмов α1 и α2. Двойственным образом определяется коуниверсальный квадрат.
Зафиксируем непустое семейство объектов Ai, i∈I некоторой
категории C и рассмотрим все конусы (αi:U→Ai, i∈I ) с данными
концами Ai, i∈I.
Определение 33. Конус (πi:U→Ai, i∈I) называется произведением (произведение можно было бы определить как универсальный конус относительно пустого коконуса) семейства объектов
87
Ai, i∈I, если для каждого конуса (αi:U→Ai, i∈I) существует такой
единственный морфизм αi:U→A, что
α i = απ i , i Î I. (2.4)
Если (πi:A→Ai, i∈I) – произведение семейства объектов Ai, i∈I,
то морфизмы πi, i∈I называются проекциями произведения. Часто под произведением семейства объектов Ai, i∈I понимается
вершина A конуса (πi:A→Ai, i∈I). Для обозначения произведения
семейства объектов Ai, i∈I используется запись
A = Õ´
iÎI Ai π i .
Морфизм α из формулы (2.4) будет обозначаться так:
α = (´)iÎI α i ,
при этом формула (2.4) принимает вид
α i = [(´)iÎI α i ]π i , i Î I. (2.5)
Определение 34. Объект A называется копроизведением (или
суммой) семейства объектов Ai, i∈I, если имеется такой коконус
(σi: Ai→B, i∈I), что для любого коконуса (αi: Ai→B, i∈I) существует такой единственный морфизм α:A→B, что
(2.6)
α i = σi α, i Î I. Морфизмы σi, i∈I называются вложениями копроизведения.
Для обозначения копроизведения семейства объектов Ai, i∈I
будет использоваться запись
A = Õ *iÎI Ai σi .
Морфизм a из формулы (2.6) будет обозначаться так:
α = (*)iÎI α i ,
при этом формула (2.5) принимает вид
(2.7)
α i = σi [(*)iÎI α i ], i Î I. Говорят, что категория C допускает экспоненцирование, если
в ней существует произведение любых двух объектов и если для
любых двух объектов a и b существует отображающий объект ba
(отображение объекта a в объект b), называемый экспоненциалом, и отображение (стрелка) ev: ba ×a→b, называемое отображением значения. Например, если A и B – конечные множества с
88
m и n элементами соответственно, то множество BA (множество
всех функций из A в B, поэтому отображающие объекты также
называются пространствами функций) также конечно и имеет
nm элементов. В выражении nm число m называется экспонентой
[82].
Многие категории обладают произведениями и суммами, но
только некоторые имеют отображающие объекты. Категории с
произведениями, в которых каждая пара имеет отображающий
объект, называются декартово замкнутыми. Замкнутость означает, что отображение от одного объекта в другой не образует ничего вне категории.
Декартово замкнутые категории являются в настоящее время
одним из базисов для формального моделирования программного обеспечения.
Определение 35. (Ковариантным одноместным) функтором Ф
из категории C1 в категорию C2 (обозначение: Ф: C1 → C2) называется пара отображений
ФOb: Оb(C1) → Ob(C2),
ФMor: Mor(C1) → Mor(C2)
(в дальнейшем мы пишем Ф вместо ФOb или ФMor), такие что:
1) α ∈ H(A, B) ⇒ Фα ∈ H(Ф(A), Ф(B));
2) Ф(1A) = 1Ф(A), для любого A ∈ Оb(C1);
3) Ф(αβ) = Ф(α)Ф(β), где α: A → B и β: B → D – произвольны.
Если вместо условий 1), 3) имеют место
4) α ∈ H(A, B) ⇒ Фα ∈ H(Ф(B), Ф(A));
5) Ф(αβ) = Ф(β)Ф(α),
то функтор Ф называется контравариантным.
Функтор Ф называется унивалентным, если ФMor – вложение.
Пусть С – некоторая категория. Построим по ней новую категорию Сор: Оb(Сор) = Ob(Сop), Hop(A, B) = H(B, A). Eсли α, β ∈
∈ Mor(Сop) – пара последовательных морфизмов, αβ = βα, где
справа композиция в С. Легко видеть, что так определенная
композиция удовлетворяет аксиомам из определения категории. Категория Сор называется двойственной к категории С. Кофункторы из С – это в точности функторы из Сор. Аналогичную
двойственность можно усмотреть в пунктах 2), 3), 5) определения 23, понятия, введенные в пунктах 1), 4), самодвойственны. В
дальнейшем мы определяем лишь одно из двух двойственных по89
нятий, считая второе автоматически определенным с помощью
перехода к двойственной категории. То же относится ко всем
утверждениям. Другими словами, мы пользуемся следующей
метатеоремой, выражающей принцип категорной двойственности: если в определении или теореме теории категорий обратить
все стрелки, то полученное высказывание снова будет определением или теоремой теории категорий.
Пусть Ф1,2: С1 → С2 – пара функторов из С1 в С2.
Определение 36. Естественным преобразованием Ф1 в Ф2 называется отображение
h: Ob(С1) → Mor(С2),
h: A  hA,
такое, что:
1) hA: Ф1(A) → Ф2(A), для любого A ∈ Оb(С);
2) коммутативна диаграмма:
" I"
   
 #
 "
I#
 #
где α: A → B – произвольный морфизм из K1.
Естественное преобразование называется эквивалентностью,
или изоморфизмом функторов, если все hA, изоморфизмы.
Если h: Ф1 → Ф2 и g: Ф2 → Ф3 – естественные преобразования,
то формула
(hg)A = hAgA
определяет преобразование hg: Ф1 → Ф3, называемое композицией преобразований h и g.
Определение 37. Категория С1 изоморфна С2, если найдется такая пара функторов Ф: C1 → C2 и Ψ: C2 → C1, что: ФΨ = 11;
ΨФ = 12, где ФΨ, ΨФ – композиции функторов, а 1i – тождественный функтор из категории Ci в себя. Категория C1 эквивалентна
C2, если вместо равенств имеют место эквивалентности функторов.
Пусть C – произвольная категория и A ∈ Ob(C). Введем основной функтор, отвечающий объекту A:
НA: C → Set;
90
НA(B) = HC(A, B),
HA(ϕ): HA(B) → HA(D), HA(ϕ): α  αϕ,
где Set – категория множеств и отображений; ϕ: B → D, α: A →
B – произвольные морфизмы. Двойственный объект называется
основным кофунктором и обозначается НA.
Пусть НC – категория, объекты которой – основные функторы, а морфизмы – естественные преобразования. Легко видеть,
что это действительно категория относительно введенной выше
композиции преобразований. Соответствующую категорию кофункторов обозначим НC. Важность понятия основного функтора видна из следующей теоремы.
Теорема 1. Имеются следующие изоморфизмы категорий:
C ≅ HC,
Cop ≅ HC,
HC ≅ (HC)op.
Доказательство представлено, например, в работе [83]. Данная теорема означает, что всякое высказывание о категории C
может быть переведено на язык основных функторов. Например:
α – мономорфизм тогда и только тогда, когда естественное преобразование τ(α) инъективно, т. е. инъективны все τ(α)A; α – постоянный морфизм тогда и только тогда, когда τ(α) – постоянно,
т. е. все τ(α)A постоянны.
Определение 38. Функтор Ф: C → Set называется представимым, если найдется такой объект A из C, что Ф ≅ НA, т. е. имеется, по крайней мере, одна эквивалентность функторов. Мы будем
говорить, что Ф представлен объектом A, если фиксирован некоторый изоморфизм Ф → НA.
Определение 39. Объект Т категории C называется терминальным, если Н(A, Т) – одноэлементное множество для любого
A ∈ Ob(C).
Пусть C1 и C2 – две категории и A ∈ Ob(C2). Введем в рассмотрение постоянный функтор Θ(A): C1 → C2:
Θ(A): B  A, ϕ  1A,
где B ∈ Ob(C1) и ϕ ∈ Моr(C1). Заметим, что Θ(A) можно рассматривать и как кофунктор.
Пусть singleton ∈ Ob(Set) – одноэлементное множество. Объект Т категории C терминален тогда и только тогда, когда ко91
функторы НТ и Θ(singleton) изоморфны. Другими словами, терминальный объект – это, в точности, объект, представляющий
постоянный кофунктор Θ(singleton). Двойственно определяется
инициальный объект категории. Для терминальных и инициальных объектов мы будем использовать термин «универсальный».
Легко видеть, что универсальный объект определен однозначно с
точностью до единственного изоморфизма.
Теорема 2. Если C имеет терминальный объект и в ней для любой пары стрелок с общим концом существует обратный образ, то
она конечно полна [81].
В терминах свойства универсальности можно описать представляющие объекты функторов, установив тем самым обратную
связь. Пусть Ф: C → Set – некоторый функтор. Введем в рассмотрение категорию CФ:
Ob(CΦ )∪ AÎOb(C) Φ( A);
H(a, b) = {f : A ® B / [Φ(f )](a) = b},
a Î Φ( A), b Î Φ(B).
Легко видеть, что CФ – категория относительно индуцированной из C композиции. Имеет место следующая лемма.
Лемма 3. Функтор Ф представим тогда и только тогда, когда в
CФ существует инициальный объект.
Доказательство можно найти в работе [83].
Из леммы следует, что если Ф представим объектом A, то пара
(A, аh ∈ Ф(A)) единственна, с точностью до изоморфизма, т. е. для
двух пар (A, a) и (A’, a’) найдется единственный изоморфизм g: A
→ A’, такой, что [Ф(g)](a) = a’. Назовем (A, аh) представляющей
парой функтора Ф.
Заметим, что соответствие Θ: A  Θ(A) очевидно продолжается до функтора, осуществляющего изоморфизм категорий C и категории постоянных функторов из C’ в C и их естественных преобразований. Имея это в виду, мы можем говорить о морфизмах
A → Ф, где A ∈ Ob(C) и Ф: C’ → C – произвольный функтор.
Введем в рассмотрение категорию C/Ф:
Ob(C/Ф) = { A → Ф | A ∈ Ob(C) };
HC/Ф(ϕ, ψ) = { f: A → B | fψ = ϕ },
92
¨É¾½Ê˹»ÄØ×ÒÁ¾
ǺӾÃËÔ
ÍÌÆÃËÇÉÇ»
¨É¾½¾ÄÔ
ÍÌÆÃËÇÉÇ»
¬ÆÁ»¾ÉʹÄÕÆÔ¾
ǺӾÃËÔ
Рис. 34. Взаимоотношения в теории категорий и функторов
где ϕ: A → Ф, ψ: B → Ф. (Напомним, что каждой стрелке f соответствует естественное преобразование Θ(A) → Θ(B), которое обозначается f).
Определение 40. Терминальный объект категории C/Ф называется (обратным) пределом функтора Ф и обозначается Lim(Ф).
Обратная связь между понятиями универсального объекта и
предела устанавливается следующим очевидным замечанием –
терминальный объект категории C является пределом пустого
функтора ∅ → C.
Наглядно установленные связи между основными понятиями
представлены на рис. 34 [83].
2.9.1. Категория качества
Определение 41. Категория качества. Категория качества Q
используется для представления понятия качества ПС и состоит
из объектов Ob(Q) и морфизмов Mor(Q).
Определение 42. Объекты категории качества. Класс объектов категории качества представляет концептуальные понятия,
характеризующие качество ПС (например, характеристики, подхарактеристики качества ПС, принципы проектирования ПС) и
является конечным множеством с разбиением Ob(Q) =
k
n
∪ Qi , где
i=0
i
Qi = {qm
}mi =1 – множество объектов i-го уровня иерархии, ki –
число элементов множества Qi.
На верхнем уровне иерархии находится объект q10 , отражающий само понятие качества ПС в максимальной его полноте и
целостности, поэтому k0 =1 на следующих уровнях иерархии количества объектов удовлетворяет формуле ki+1 ≥2ki, i∈{1, …n–1}.
При этом Qi ∩ Qj = ∅ при i ≠ j, т. е. каждая характеристика ка-
93
чества находится на одном определенном уровне иерархии. С целью обобщения существующих и будущих стандартов и моделей качества объектами категории являются все потенциально
оцениваемые атрибуты, связанные с качеством ПС. Для обеспечения согласованности каждый такой атрибут отражает ровно
одну концепцию качества, и каждой концепции качества соответствует ровно один атрибут. Определяются процедуры добавления объектов к категории качества, учитывающие ограничение взаимно однозначного соответствия атрибутов и концепций
качества.
Лемма 4. Категория качества является малой категорией.
Доказательство. По построению, в соответствии с определением 42, объекты категории качества образуют конечное множество. Отсюда следует, что категория качества – малая.
Определение 43. Морфизмы категории качества. Класс морфизмов категории качества описывается тремя множествами
Mor(Q) = Morsi(Q) ∪ Mordi(Q) ∪ Morsl(Q) – множеством строгих
иерархических морфизмов Morsi(Q), множеством нестрогих иерархических морфизмов Mordi(Q) и множеством одноуровневых
морфизмов Morsl(Q).
Определение 44. Строгие иерархические морфизмы категории качества:
1) для любых двух объектов qai ,qbi Î Qi , i∈{1,…,n} определяется множество морфизмов Morsi (qai ,qbi ) из qai в qbi :
ì
ïÆ, a ¹ b
Morsi (qai ,qbi ) = ï
í{1 }, a = b, где 1q i – тождественный морi
a
ï
ï
î qa
физм объекта qai ;
2) для любых двух объектов qai+1 Î Qi+1,qbi Î Qi , при i∈{1,…,
n–1}, a∈{1,…,ki}, b∈{1,…,ki+1}, множество морфизмов определяется пустым Morsi (qai+1,qbi ) = Æ;
3) для любого объекта qbi Î Q i могут существовать объекты
вида qai-1 Î Qi-1, такие, что Morsi (qai-1,qbi ) состоит из одного морb
b
физма для каждого объекта qai-1. Для всех остальных объектов
b
qai-1 Î Qi-1 при aj≠ab множество морфизмов задается пустым:
j
ïìï{ξi-1,i }, a = ab ,
Morsi (qai-1,qbi ) = í a,b
.
ïïÆ, a ¹ a
b
ïî
94
Таким образом, кроме тождественного, не существует других
видов строгих иерархических морфизмов на одном уровне иерархии категории качества. Остальные строгие морфизмы определяют связи верхнего уровня иерархии с нижним, например, как
связи характеристик с подхарактеристиками, подхарактеристик с принципами проектирования. Возможна ситуация, когда
несколько объектов верхнего уровня связаны с одним объектом
нижнего множеством морфизмов (по одному морфизму на каждый объект верхнего уровня).
i k
i k
Для трех подмножеств Qi1 = {qa1 }ai1=1, Qi2 = {qa2 }ai2=1 и
i k
Qi3 = {qa3 }ai3=1,
3
3
1
если множества
1
2
i
i
Morsi (qa1 ,qa2 )
1
2
являются пустыми, определяется
2
i
i
и Morsi (qa2 ,qa3 ) не
2
3
i1 i3
множество Morsi (qa ,qa ), со1
3
стоящем из одного морфизма, который является произведением
i ,i
i ,i
морфизмов ξa1 ,2a и ξa2 ,3a :
1 2
2 3
i
i ,i
i
i
i ,i
i
((Morsi (qa1 ,qa2 ) = {ξa1 ,2a }) Ù (Morsi (qa2 ,qa3 ) = {ξa2 ,3a })) Þ
1
2
1
2
i
i
i ,i
Þ Morsi (qa1 ,qa3 ) = {ξ a1 ,3a
1
3
1 3
2
i ,i
= ξ a1 ,2a
1 2
3
2
3
i ,i
 ξa2 ,3a }.
2 3
Произведения морфизмов отвечают отношениям «характеристика – подхарактеристика – принцип проектирования» все более глубоких уровней иерархии.
Определение 45. Нестрогие иерархические морфизмы категории качества:
1) для любых двух объектов qai ,qbi Î Qi , i∈{1,…,n} определяется множество морфизмов Mordi (qai ,qbi ) из qai в qbi :
ìïÆ, a ¹ b
Mordi (qai ,qbi ) = ïí
;
ïï{1q i }, a = b
î a
2) для любых двух объектов qaj Î Qj ,qbi Î Qi при i,j∈{0,…,n–1},
i<j, a∈{1,…,ki}, b∈{1,…,ki+1} множество морфизмов определяется
пустым Mordi (qai+1,qbi ) = Æ;
3) для любого объекта qbj Î Q j могут существовать объекты вида qai Î Qi , при j>i+1, такие, что Mordi (qai ,qbj ) состоит из
b
b
одного морфизма для каждого объекта qai . Для всех остальных
b
объектов qai Î Qi при aj≠ab множество морфизмов задается пуl
стым:
95
ìï{ξ i,j }, a = a
ï
b
.
Mordi (qai ,qbj ) = í a,b
ïïÆ, a ¹ a
b
ïî
Нестрогие иерархические морфизмы служат для описания
связей разных, не соседних уровней иерархии.
Определение 46. Одноуровневые морфизмы категории качества:
1) для любых двух объектов qai ,qbi Î Qi , i∈{1,…,n} определяется множество морфизмов Morsl (qai ,qbi ) из qai в qbi :
ìï{ ξ i,j }, a ¹ b
ï a,b
Morsl (qai ,qbi ) = ïí
;
ïï{1 i }, a = b
ïî qa
2) для любых двух объектов qai Î Qi ,qbj Î Qj , i,j∈{1,…,n}
множество одноуровневых морфизмов является пустым
Morsl (qai ,qbj ) = Æ.
Одноуровневые морфизмы служат для моделирования взаимовлияний объектов качества, находящихся на одном уровне иерархии.
Категория качества содержит морфизмы, отражающие все
возможные связи атрибутов качества. Для иерархических морфизмов принципиальное значение имеет направленность – от
объектов, находящихся на верхних уровнях иерархии, к объектам, расположенным на нижних. Иерархические морфизмы от
верхних к нижним объектам образуют конусы. Эта направленность определяет главное назначение модели качества – последовательное, детализируемое на каждом следующем уровне иерархии, концептуальное описание понятия качества ПС.
Лемма 5. Конусы категории качества, образуемые иерархическими морфизмами, являются произведениями.
Доказательство. Приведем доказательство для строгих
иерархических морфизмов. Зафиксируем непустое семейство объектов qbj , j Î 1,...,n; k Î I некоторой категории качеk
ства и рассмотрим все конусы (ξia,,jb : qai ¢ ® qbj , i Î 0,...,n -1;
k
k
j Î 1,...,n; k Î I) с данными концами qbj , j Î 1,...,n; k Î I. Коk
нус (π ia,,jb : qai ® qbj , i Î 0,...,n -1; j Î 1,...,n; k Î I) является проk
k
изведением семейства объектов qbj , j Î 1,...,n; k Î I, если для
k
каждого конуса (ξia,,jb : qai ¢ ® qbi , i Î 0,...,n -1; j Î 1,...,n; k Î I)
k
k
существует такой единственный морфизм α : qai ¢ ® qai , что
i,j
i,j
ξa,b = απ a,b , i Î 0,...,n -1; j Î 1,...,n; k Î I.
k
96
Из способа определения строгих иерархических морфизмов
категории качества следует, что объекты qai ¢ и qai совпадают, α
является тождественным морфизмом. Аналогично доказывается существование произведения в случае конусов, образованных
нестрогими иерархическими морфизмами, а также конусов, сочетающих строгие и нестрогие иерархические морфизмы.
В дальнейшем изложении под произведением семейства
объектов qbj , j Î 1,...,n; k Î I понимается вершина qai конуса
k
(ξia,,jb : qai ® qbj , i Î 0,...,n -1; j Î 1,...,n; k Î I).
k
k
произведения семейства объектов
ся запись
Для
qbj , j Î 1,...,n; k Î I
k
обозначения
использует-
qai = Õ´jÎ1,...,n;kÎI qbj .
k
Определение 47. Независимость объектов категории качества.
Объекты категории качества qai , i Î 1,...,n -1 и qcl , l Î 1,...,n -1 являются независимыми, если соблюдаются следующие условия:
1) отсутствуют одноуровневые морфизмы между этими объектами:
Morsl (qai ,qcl ) = Æ при i=l;
2) отсутствуют строгие иерархические морфизмы между этими объектами:
Morsi (qai ,qcl ) = Æ при i≠l;
3) отсутствуют нестрогие иерархические морфизмы между
этими объектами:
Mordi (qai ,qcl ) = Æ при i≠l;
4) подмножества морфизмов, входящих в продолжения конусов, имеющих в качестве вершин объекты qai и qjb , не пересекаются:
(∪ j=1,...,n;kÎI qai ® qkj ) Ç (∪ h=1,...,n;gÎI qcl ® qgh ) = Æ.
Определение 48. Модель качества ПС. Модель качества ПС
представляет собой подкатегорию категории качества.
Модель качества ПС состоит из конечного числа объектов категории качества и конечного числа морфизмов между ними.
Модель может представлять некоторый международный или государственный стандарт (например, ГОСТ Р ИСО/МЭК 9126-93,
ISO/IEC 25000 и т. п.), стандарт предприятия-разработчика ПС
97
98

R
OsO
O
O
R
R
O
OsO

R

OsOs

R
O

O

O
R
R
R
OsO

R
O
OsO



Us
O
Q
Рис. 35. Схема модели качества
OsO

R

Q
R
SUs
R
Us
O
OsO
R
O
S
U
O
SU
OsO
R

и т. п. В подкатегорию категории качества выбираются объекты,
представляющие концепции качества ПС, исходя из назначения
модели.
На рис. 35 приведена структура модели качества в схематическом виде.
В качестве примера рассмотрим фрагмент модели качества,
представляющей стандарт ISO/IEC 25000, в который выделим
иерархию показателей, порождаемую характеристикой «Удобство сопровождения». Согласно стандарту ISO/IEC 25000, эта
характеристика зависит от подхарактеристик «Удобство проверки», «Стабильность», «Удобство внесения изменений», «Анализируемость» и «Соответствие стандартам сопровождения».
Декомпозируем подхарактеристики качества на ряд принципов
проектирования применительно к объектно-ориентированному
стилю. Это принципы:
– «высокое сцепление», отражающий необходимость усиления использования методами внутренней структуры того же
класса;
– «низкая связность», состоящий в уменьшении межклассовых зависимостей;
– «отсутствие классов-данных», т. е. классов, использующихся только в качестве структур данных для методов других классов;
– «отсутствие классов-монстров», проявляющегося в существовании большого и сложного класса, который мало зависит от
остальных классов и предоставляет им мало функциональности.
Результирующая модель качества показана на рис. 36.
2.9.2. Реализация требований
формального моделирования качества
1. Возможность описания качества в абстрактном, не зависимом от реализации виде. Категория качества содержит все
возможные объекты, отражающие различные концептуальные
понятия о качестве ПС. Эти концептуальные элементы могут
быть сколь угодно абстрактными и сколь угодно конкретными.
Выбор подмножества объектов категории качества и построение на их основе модели обуславливаются целями моделирования. Итоговая модель может быть как абстрактной, не зависимой от реализации, так и детализированной, а может и сочетать
на разных уровнях иерархии абстрактные и детализированные
элементы.
99
100
R
›ÔÊÇÃǾ
ÊϾÈľÆÁ¾
¨Ç½Î¹É¹Ã˾ÉÁÊËÁÃÁ
   

R
R   R §ËÊÌËÊË»Á¾ R ÃĹÊÊÇ»ÅÇÆÊËÉÇ»  ™Æ¹ÄÁÀÁÉ̾ÅÇÊËÕ
§ËÊÌËÊË»Á¾
ÃĹÊÊÇ»½¹ÆÆÔÎ

Рис. 36. Пример модели качества

¬½ÇºÊ˻ǻƾʾÆÁØ R ÁÀžƾÆÁÂ
  R ¬½ÇºÊË»Ç
ÊÇÈÉǻǿ½¾ÆÁØ
ªË¹ºÁÄÕÆÇÊËÕ
¦ÁÀùØÊ»ØÀÆÇÊËÕ R R ¨ÉÁÆÏÁÈÔ
ÈÉǾÃËÁÉÇ»¹ÆÁØ
 R ¬½ÇºÊË»Ç
ÈÉÇ»¾ÉÃÁ
®¹É¹Ã˾ÉÁÊËÁÃÁ
›ÆÌËɾÆƾ¾Á
»Æ¾Ñƾ¾
ùоÊË»Ç
2. Необходимость формализации связей характеристик разных уровней в иерархической структуре модели качества. Для
формализации иерархических связей служат иерархические морфизмы категории качества. В зависимости от требований моделирования в модель качества могут быть включены только строгие
иерархические морфизмы. Это позволит иметь четко очерченные
уровни модели качества. На каждом таком уровне будут располагаться объекты определенной степени абстракции. Такого рода
конфигурация модели соответствует моделям стандарта ISO/IEC
25000. В некоторых моделях может быть обусловлено появление
связей объектов несмежных уровней. Это достигается использованием нестрогих иерархических морфизмов. Таким способом
можно осуществить формальное описание модели в соответствии
со стандартом IEEE 1061. Для большинства моделей может оказаться целесообразным введение ограничения на пустоту множества нестрогих иерархических морфизмов, что позволит иметь
модель с четкими уровнями иерархии объектов качества.
3. Наличие механизма по добавлению или удалению характеристик разного уровня и связей между ними. Это требование реализуется выбором подходящего состава объектов и морфизмов
категории качества и построением на их основе подкатегории –
модели качества. По мере работы с этой моделью допускается
расширять как набор объектов путем включения в состав подкатегории других объектов категории качества, так и связи между
ними путем добавления морфизмов из категории.
4. Однозначность толкования характеристик и подхарактеристик качества ПС. Категория качества является малой категорией, т. е. ее объекты образуют множество, каждый объект является уникальным. Главным принципом включения объекта в
категорию является взаимнооднозначное соответствие объектов
категории и концепций качества, т. е. для того, чтобы была возможность добавить новый элемент к классу объектов категории
качества, нужно:
– определить концепцию, моделированию которой будет посвящен новый элемент;
– обосновать отсутствие среди объектов категории качества
объекта, моделирующего семантически эквивалентную концепцию.
Наделение каждого объекта уникальными свойствами делает
однозначным концептуальную интерпретацию объектов качества.
101
5. Возможность существования проекций модели качества с
точки зрения основных участников создания ПС. Это требование
реализуется путем определения подкатегорий категории качества, каждая из которых содержит в качестве объектов элементы, отражающие специфическую интерпретацию компонентов
качества со связями, отображаемыми морфизмами этих подкатегорий. Каждому объекту одной модели-проекции должны соответствовать в смысле существования морфизмов объекты другой
модели-проекции.
6. Возможность существования зависимостей между одноуровневыми характеристиками качества. Для реализации этой
возможности введено множество одноуровневых морфизмов категории качества. Следует отметить, что рекомендуется избегать
использования одноуровневых морфизмов в целях, отличных
от создания проекций модели с точки зрения разных участников процесса, так как это продуцирует зависимости не только
одноуровневых, но и вышестоящих по иерархии объектов, что
может отразиться на согласованности модели качества. Тем не
менее для возможности формального представления тех моделей
и стандартов качества, которые предполагают существование
зависимых одноуровневых объектов, а также для возможности
формирования проекций объектов качества категория качества
содержит множество одноуровневых морфизмов.
7. Возможность классификации характеристик качества, например, на внешние и внутренние, для повышения применимости модели. Это требование реализуется определением соответствующих подкатегорий качества. В эти подкатегории должны
попадать объекты, объединенные общей концептуальной направленностью, например, объекты, соответствующие видению
заказчика, объекты, отражающие точки зрения разработчиков
или менеджеров, с включением соответствующих морфизмов
между этими объектами.
8. Возможность совмещения характеристик, в силу того, что
они могут различными способами затрагивать разные свойства
ПС. Под совмещением понимается возможность существования
зависимости нескольких объектов i-го уровня от одного объекта
j-го уровня при j>i. Если j=i+1, то для реализации этой возможности необходимо использовать строгие морфизмы категории качества. В соответствии с определением 44, объект i+1-го уровня
может быть связан с несколькими объектами i-го уровня множе102
ством строгих иерархических морфизмов. Если j>i+1, то нужно
использовать нестрогие иерархические морфизмы. По определению 45, объект j-го уровня может быть связан с несколькими
объектами i-го уровня при j>i+1 множеством нестрогих иерархических морфизмов.
9. Возможность существования связей между характеристиками не только смежных уровней иерархии. Реализуется введением в модель качества, наряду со строгими, нестрогих иерархических морфизмов. Следует отметить, что использование нестрогих иерархических морфизмов ухудшает структурированность
модели качества. При использовании только строгих иерархических морфизмов удается четко разделить ответственности уровней иерархии модели, объединив в уровень иерархии объекты с
эквивалентным концептуальным назначением.
10. Возможность формальной проверки независимости листовых элементов модели качества. Согласно определению 47, два
листовых объекта qai , i Î 1,...,n -1 и qcl , l Î 1,...,n -1 являются независимыми, если между ними отсутствуют одноуровневые морфизмы:
Morsl (qai ,qcl ) = Æ при i=l.
Чтобы убедиться в независимости всех листовых объектов модели качества, достаточно убедиться в том, что множество одноуровневых морфизмов пусто: Morsl=∅.
11. Возможность формальной проверки отсутствия в аналитических выражениях для характеристик и подхарактеристик
зависимых компонентов. Согласно определению 47, два объекта
qai , i Î 1,...,n -1 и qcl , l Î 1,...,n -1 являются независимыми, если
соблюдаются следующие условия:
1) отсутствуют одноуровневые морфизмы между этими объектами:
Morsl (qai ,qcl ) = Æ при i=l;
2) отсутствуют строгие иерархические морфизмы между этими объектами:
Morsi (qai ,qcl ) = Æ при i≠l;
3) отсутствуют нестрогие иерархические морфизмы между
этими объектами:
Mordi (qai ,qcl ) = Æ при i≠l;
103
4) подмножества морфизмов, входящих в продолжения конусов, имеющих в качестве вершин объекты qai и qjb , не пересекаются:
(∪ j=1,...,n;kÎI qai ® qkj ) Ç (∪ h=1,...,n;gÎI qcl ® qgh ) = Æ .
12. Существование механизма минимизации состава компонент, включаемых в выражения для характеристик и подхарактеристик. Это требование реализуется путем анализа зависимостей, определяемых морфизмами, принадлежащими Morsi, Mordi
и Morsl. При наличии зависимости двух объектов в терминах
определения 47 осуществляется попытка удаления одного из зависимых объектов и включения другого в конусы вышестоящих
объектов.
13. Существование механизма проверки наличия одинаково
выраженных характеристик и подхарактеристик. Для реализации требований ищутся все зависимые в терминах определения
47 объекты, затем осуществляется исследование степени концептуальной схожести выражений для зависимых объектов.
14. Необходимость учета принципов проектирования для возможности их дальнейшего оценивания и обеспечения причинноследственной связи между качеством ПС и принципами принятия проектных решений в той или иной парадигме. Реализуется
путем моделирования принципов проектирования в виде объектов категории качества q∈Ob(Q). Вторым способом учета принципов проектирования является введение понятия роли в формальную модель ПС. Каждая сущность ПС может выполнять набор
ролей в системе с точки зрения принципов проектирования, на
взаимодействие ролей накладываются правила, описывающие
принципы проектирования, модели и код ПС можно подвергать
анализу чистоты следования принципам проектирования на
основе исследования взаимосвязей ролей.
15. Необходимость в целом соответствовать всему положительному опыту, накопленному исследователями качества ПС,
стандартам и технологиям, применяемым в этой области. В силу
своего устройства категория качества обобщает все значимые наработки в области моделирования качества. С помощью подходящей подкатегории (модели) качества может быть представлена
любая из существующих, стандартизованных и использующихся моделей качества.
104
Глава 3. Оценивание
качества программных средств
3.1. Модель измерений программных средств
3.1.1. Измерение качества программных средств
Модели качества формировались как основа для измерений
и оценивания качества ПС. Более ранние подходы в основном
давали качественные измерения, тогда как поздние разработки
включают все больше количественных метрик, позволяющих
сделать процесс оценивания качества ПС в большей степени объективным и автоматизированным. Измерения служат основой
для понимания процессов разработки и самой ПС и используются в следующих качествах [34]:
– основы оценивания качественных свойств ПС;
– средства оценивания процессов разработки ПС;
– инструмента анализа дефектов ПС;
– основы для оценивания опыта разработки ПС.
В работе [85] приводится обобщенная модель процесса измерения, адаптированный вариант которой представлен на рис. 37.
Одними из наиболее фундаментальных работ по измерению
качества являются [53], заложившие основы для процессов измерений свойств ПС.
Теоретическое ядро квалиметрии образует теория оценивания, в которой рассматриваются закономерности, принципы,
логика и алгоритмы оценивания качества объектов и процессов.
Согласно этой теории, модель оценивания качества представляется в виде кортежа <S,O,B,L>, который включает субъект S,
объект O, базу B и логику оценивания L. В систему квалиметрического оценивания закладывается принцип сравнения. В оценивании качества объединяются деятельный, алгоритмический
¡ÆÊËÉÌžÆËÔÁÀžɾÆÁÂ
›Îǽ
¡ÀžɾÆÁ¾
ž½ÁÆÁÏÔÁÀžɾÆÁÂ
ÑùÄÔ
©¾ÀÌÄÕ˹Ë
¶Ë¹ÄÇÆÔ
Рис. 37. Обобщенный процесс измерения
105
и логический аспекты. Деятельный аспект отражает организацию оценивания с учетом субъект-объектных отношений по
оцениванию и управлению качеством. Алгоритмический аспект
реализуется посредством операций измерения и оценивания качества в алгоритмах оценивания. Логический аспект раскрывает
логику оценивания качества, выбор базы оценивания, основные
принципы и аксиомы оценивания. Основные положения теории
оценивания формулируются в виде следующих аксиом:
– подчиненности системных сравнений (система сравнения
при оценке качества определена субъект-объектными отношениями по оцениванию и управлению качеством);
– определения границ сравнения качеств (оцениваемое качество всегда сравнивается в определенных границах сравнения,
характеризуемых компонентами системы оценивания);
– существования базы сравнения (любая операция сравнения
выполняется при наличии определенной базы сравнения);
– абсолютной сравнимости (сравнимость качеств абсолютна, а
их несравнимость относительна);
– полноты отношения сравнимости (отношение сравнимости
обязательно включает или отношение тождества, или отношения
различия, или отношения тождества и различия одновременно).
Для определения значений качественных атрибутов используются следующие методы:
– измерительный (определение показателей качества базируется на использовании средств измерений);
– регистрационный (осуществляемый на основе наблюдения
и подсчета числа определенных событий, предметов и расходов);
– эргонометрический (осуществляется на основе анализа восприятий органов чувств);
– аналитический (предполагает использование расчетноаналитических зависимостей показателей качества продукции
от ее параметров для определения оценочных показателей, характеризующих единичные или комплексные свойства качества,
а также для формирования конечного результата оценивания);
– статистический (основан на сборе статистической информации о параметрах и свойствах оцениваемой продукции и базовых
образцов ее обработки с помощью статистических процедур);
– экспертный (основан на получении обработки и контроля
информации о параметрах и свойствах оцениваемой продукции
и базовых образцов при помощи экспертных процедур);
106
– комбинированный (представляет собой комбинацию аналитического, статистического и экспертного методов в различном
их сочетании).
Основные понятия теории измерений программных средств
Мы будем использовать терминологическую систему из наиболее современного стандарта по оценке качеству ПС ISO/IEC
25000 [10]. Используемые адаптированные термины представлены в табл. 8.
Таблица 8
Определения терминов теории измерений
программных средств
Термин
Семантика термина
Мера
(метрика)
Переменная, которой в результате измерения присваивается определенное значение. Термин обобщает
базовые, производные меры и индикаторы. В рамках
согласования терминологии со стандартом ISO/IEC
15939 [93], в стандарте ISO/IEC 25000 используется
термин «мера», а не «метрика» – эквивалентный по
смыслу термин стандарта ISO/IEC 9126 [26–29]. Мы
будем термины «мера» и «метрика» использовать как
синонимы
Базовая
мера
Мера, определенная в терминах атрибута и метода его
обсчета. Базовая мера является функционально независимой от других мер
Производная мера
Мера, которая определяется посредством функции от
двух или более значений базовых мер. Преобразование
базовой меры с использованием математических функций также является производной мерой
Внешняя
мера
Базовая или производная мера внешнего атрибута ПС
Внутренняя
мера
Базовая или производная мера внутреннего атрибута
ПС
Мера качеМера атрибута качества в использовании
ства в использовании
Метод оценивания
Процедура, содержащая действия, которые необходимо
выполнить субъекту оценивания для получения результатов определенных измерений заданных компонентов ПС или ПС в целом
107
Окончание табл. 8
Термин
Семантика термина
Модуль оценивания
Пакет технологии оценивания для измерения характеристик, подхарактеристик или атрибутов качества.
Пакет инкапсулирует методы и техники оценивания,
выходные данные, подлежащие оценке, данные, которые необходимо измерить. Пакет объединяет и поддерживает процедуры и средства оценивания
Измерение
Набор операций, предназначенных для установления
значения меры
Функция из- Алгоритм или вычисление, выполняемые с целью
мерения
объединения двух или более базовых мер
Метод измерения
Общее описание логической последовательности операций, которые используются для определения численного значения атрибута в соответствии с определенной
шкалой
Процедура
измерения
Детально описанный набор операций, используемый
для выполнения определенного измерения в соответствии с конкретным методом измерения
Процесс измерения
Процесс создания, планирования, выполнения и измерения ПС в рамках проекта или организационной
структуры
Ранжирование
Действия по отображению измеренного значения на соответствующий уровень ранжирования. Используется
для определения уровня ранжирования, связанного с
ПС для определенной характеристики качества
Шкала
Непрерывное или дискретное упорядоченное множество значений или множество категорий, на которые
отображаются атрибуты ПС
Уровень ран- Точка на шкале, используемая для категоризации
жирования шкалы измерений. Уровень ранжирования позволяет
создавать классификации ПС в соответствии с определенными или подразумеваемыми потребностями.
Определенные виды уровней ранжирования могут быть
связаны с различными проекциями качества (например, с точки зрения пользователей, менеджеров, разработчиков)
Оценивание
ПС
108
Техническая операция, состоящая в оценивании одной
или нескольких характеристик ПС, выполняемая в соответствии с определенной процедурой
Шкалы измерений
¡ÀžɾÆÆÔ¾
ÀƹоÆÁØ
®ÇÉÇÑÁÂ
¬Ê˹ÆǻľÆÆÔÂ
ÌÉÇ»¾ÆÕ
ªÉ¾½ÆÁÂ
¦ÁÀÃÁÂ
±Ã¹Ä¹Å¾ËÉÁÃÁ
¦¾Ì½Ç»Ä¾Ë»ÇÉÁ˾ÄÕÆÇ
§ËÄÁÐÆÔÂ
¬½Ç»Ä¾Ë»ÇÉÁ˾ÄÕÆÇ
Шкалой измерений называют принятый по соглашению порядок определения и обозначения всевозможных проявлений
(значений) конкретного свойства (величины) (рис. 38). Шкала
представляет собой множество числовых или категорных значений (в том числе упорядоченных), на которое отображается измеряемый атрибут качества. С помощью метода измерения величина измеренного атрибута отображается на некоторое значение
шкалы.
Различают пять основных типов шкал измерений: номинальные, порядковые, интервальные, относительные и абсолютные.
Номинальные шкалы
Номинальные шкалы отражают качественные свойства. Их
элементы характеризуются только соотношениями эквивалентности (равенства) и сходства конкретных качественных проявлений свойства. Эти шкалы не имеют нуля и единиц измерений, в
них отсутствуют отношения сопоставления типа «больше – меньше». На номинальной шкале нельзя производить арифметические действия. Возможно появление неопределенности результата измерений. Измерение сводится к сравнению измеряемого
объекта с эталонным и выбору одного из них (или двух соседних),
совпадающего с измеряемым.
Порядковые шкалы
Сравнение одного размера с другим по принципу «что больше»
или «что лучше» производится по шкале порядка. Порядковые
Рис. 38. Шкалирование измеренных значений
109
Рис. 39. Порядковая шкала
шкалы можно представить как расширение номинальных шкал
введением отношений частичного порядка (рис. 39). Расстановка
размеров по мере возрастания или убывания для получения измерительной информации по шкале порядка называется ранжированием. По шкале порядка сравниваются между собой размеры,
которые сами остаются неизвестными. Результатом сравнения
является ранжированный ряд. Математической моделью теоретического сравнения между собой двух размеров одной меры по
шкале порядка служит неравенство Mi≤Mj (Mi≥Mj), а результат
сравнения – решение о том, какой размер больше другого, или
они равны. Если все расчеты верны, то результат вычислений –
решение – является правильным. Измерения по шкале порядка
являются самыми несовершенными, наименее информативными. Они не дают ответа на вопрос о том, на сколько или во сколько раз один размер больше другого. На шкале порядка могут
выполняться лишь некоторые логические операции. Например,
если первый размер больше второго, а второй больше третьего, то
и первый больше третьего. Если два размера меньше третьего, то
их разность меньше третьего. Эти свойства шкалы называются
свойствами транзитивности. В то же время на шкале порядка не
определены никакие арифметические действия. Для облегчения
измерений на шкале порядка можно зафиксировать некоторые
опорные точки в качестве реперных. Такая шкала называется
реперной. Точкам реперных шкал могут быть проставлены цифры, называемые баллами.
Недостатком реперных шкал является неопределенность
интервалов между реперными точками. Поэтому баллы нельзя
складывать, вычитать, умножать или делить. Измерительная
информация, полученная по шкале порядка, непригодна для математической обработки.
Интервальные шкалы
На шкале интервалов откладывается разность между размерами. Принцип построения шкалы интервалов для размеров, образующих ранжированный ряд M1 < M2 < M3 < M4 < M5 < M6 < M7,
показан на рис. 40. Математической моделью теоретического сравнения между собой двух размеров одной меры служит выражение
110
Mi – Mj = ∆Mij,
(3.1)
в котором при построении шкалы интервалов с размером Mj
сравниваются все размеры Mi. На рис. 40 в качестве Mj выбран
M4. Если бы в качестве Mj был выбран размер M5, произошло бы
смещение нуля вправо, а если M3 – то влево. Начало отсчета на
шкале интервалов произвольное.
На шкале интервалов определены такие математические действия, как сложение и вычитание. Интервалы с учетом знаков
можно складывать друг с другом и вычитать. Благодаря этому
можно определить, на сколько один размер больше или меньше
другого:
M7 - M5 = DM7 -DM5 ,
M5 - M2 = DM5 - (-DM2 ) = DM5 + DM2 ,
M3 - M1 = -DM3 - (-DM1 ) = DM1 -DM3 .
Аддитивные операции в этих выражениях выполняются с
размерами интервалов, полученных по формуле (3.1), т. е. по неотградуированной шкале. Если шкала отградуирована, то размеры единиц выражены в определенных единицах измерения
и приведенные выражения равенства продолжают иметь силу.
Ввиду неопределенности начала отсчета, мультипликативные
операции на шкале интервалов не определены. Соответственно,
на шкале интервалов нельзя определять, во сколько раз один размер больше или меньше другого. Иногда шкалы интервалов получают путем пропорционального деления интервала между реперными точками. Деление шкалы на рваные части – градации –
устанавливает на ней масштаб и позволяет выразить результат
.
.
.
.
.
.
.
. . .
.
.
.
Рис. 40. Интервальная шкала
111
измерения в числовой мере. При наличии масштаба измерение
на шкале интервалов сводится к подсчету числа градации, укладывающихся в интервале ∆Mij.
Относительные шкалы
Относительная шкала представляет собой интервальную шкалу, в которую добавлено понятие фактического нуля. По такой
шкале можно отсчитывать абсолютное значение размера и определять, во сколько раз один размер больше или меньше другого.
Шкала отношений является самой совершенной, наиболее информативной. На ней определены все математические действия –
сложение, вычитание, умножение и деление. Отсюда следует,
что значения любых размеров на шкале отношений можно складывать между собой, вычитать, перемножать и делить. Следовательно, можно определить, на сколько или во сколько раз один
размер больше или меньше другого. Таким образом, значение измеряемой величины – это выражение ее размера в определенных
единицах измерения. Входящее в нее отвлеченное число называется числовым значением. Оно показывает, на сколько единиц
измеряемый размер больше нуля или во сколько раз он больше
единицы. Значение измеряемой величины M определяется ее
числовым значением g и некоторым размером [M], принятым за
единицу измерения: M = g[M], где M – измеряемая величина;
[M] – единица измерения; g – числовое значение.
Увеличение или уменьшение [M] влечет за собой обратно пропорциональное изменение g. Поэтому значение, как и размер измеряемой величины, от выбора единиц измерения не зависит.
Абсолютные шкалы
Абсолютные шкалы обладают всеми свойствами шкал отношений. Назначение абсолютных шкал состоит в отражении
пропорциональных отношений между мерами, измеряемыми в
одинаковых единицах измерения. Единицы абсолютных шкал
естественны, а не выбраны по соглашению, но эти единицы безразмерны (разы, проценты, доли, полные углы и т. д.). Единицы
величин, описываемые абсолютными, не являются производными единицами СИ, так как, по определению, производные единицы не могут быть безразмерными. Это внесистемные единицы.
Абсолютные шкалы бывают ограниченными и неограниченными. Эти шкалы принципиально нелинейны. Поэтому они не имеют единиц измерений.
В табл. 9 приводятся примеры шкал и отношений между измеренными значениями.
112
Таблица 9
Шкалы и допустимые преобразования
Тип шкалы
Допустимые преобразования
(способы отношения
измерений M и M′)
Примеры
Номиналь- Отображение 1:1 между M и M′
ная
ПорядкоМонотонно возрастающая
вая
функция из M к M′, такая что из
M(x)≥M(y) следует M′(x)≥ M′(y)
ИнтерM′=aM+b,
вальная
a>0
Относительная
M′=aM a>0
Абсолютная
M′=M
Классификация,
маркирование
Жесткость, качество
воздуха
Относительное время,
температура (по Фаренгейту, Цельсию)
Интервал времени,
длина, температура
(по Кельвину)
Счетные сущности
Процесс комплексирования
Комплексированием (синонимы – «свертывание», «ранжирование») мер (метрик) качества называется их объединение, осуществляемое по тому или иному закону. Производные метрики
могут быть связаны с базовыми через функциональные зависимости или быть некоторой их комбинацией. Функциональный
способ нахождения производной метрики качества предпочтительнее, но не всегда возможен по ряду причин. Одна из них состоит в том, что получить функциональную зависимость, учитывающую большое число базовых метрик, практически сложно.
Если производную метрику невозможно выразить через базовые
с помощью объективной зависимости, применяют субъективный
способ образования производных метрик по принципу среднего
взвешенного. Субъективным в этом случае является лишь параметр логики усреднения, сама же производная метрика представляет собой объективную количественную характеристику
качества объекта. В самом общем виде производную метрику по
принципу среднего взвешенного определяют по формуле
x
n
n
j=1
j=1
M = x ( å g j Mj ) / å g j , (3.2)
113
где x – параметр логики усреднения; gj – весовые коэффициенты;
Mj – значение j-й метрики; n – число базовых метрик.
Задавая разные значения x, получаем разные виды средних
взвешенных производных показателей (табл. 10).
Таблица 10
Комплексирование метрик качества
Метод комплексирования
Параметр
логики
усреднения
Среднее
гармоническое
взвешенное
x = -1
Среднее
квадратическое
взвешенное
x=0
Среднее
геометрическое
взвешенное
x =1
Среднее арифметическое взвешенное
x=2
Математическое выражение
n
n
j=1
j=1
∼
M = å g j / ( å g j / Mj )  
(3.3)
æm
ö
m
=
ç
g ÷
M = çç Õ M j ÷÷÷1/ å gj  
çç
j ÷
÷ø j=1
è j=1
(3.4)
m
m
j=1
j=1
-
M = ( å g j Mj ) / å g j  
(3.5)
m
m

M = ( å gj M 2 ) / å gj  
(3.6)
j
j=1
j=1
По аналогии могут быть составлены и другие выражения производных метрик при иных значениях x.
На практике применяют также средние взвешенные (смешанные) метрики, образованные сочетанием (объединением) вышеперечисленных. Например:
n
n
n
n

M = ( å g j Mj ) / å g j + ( å g j M 2 ) / å g j .
j=1
j=1
j=1
j
j=1
(3.7)
С помощью весовых коэффициентов gj учитывают важность
или ценность каждой базовой метрики среди других. Для ответа
на вопрос, во сколько раз или на сколько одна метрика важнее
другой, используют экспертные и аналитические методы определения коэффициентов весомости.
В экспертных методах веса метрик обычно удовлетворяют
условию
n
å gj = 1.
j=1
114
Поэтому формулы (3.3)–(3.6) принимают вид, представленный в табл. 11.
Таблица 11
Комплексирование метрик качества (экспертные веса)
Метод комплексирования
Математическое выражение
Среднее
гармоническое
взвешенное
M = å g j Mj
Среднее
квадратическое
взвешенное
M= ÕM
Среднее
геометрическое
взвешенное
Среднее арифметическое
взвешенное
n
∼
(3.8)
j=1
=
n
j=1
gj
(3.9)
j
n
-
M = 1/ ( å gj / Mj )
(3.10)
j=1

M=
n
å gj M 2
(3.11)
j
j=1
Если базовые метрики Mj имеют одинаковые весовые коэффициенты gj = 1/n, то формулы (3.8)–(3.11) переходят в формулы,
представленные в табл. 12.
Таблица 12
Комплексирование метрик качества (равные веса)
Метод комплексирования
Среднее гармоническое
взвешенное
Среднее квадратическое
взвешенное
Математическое выражение
∼
M = 1/
=
1 n 1
å
n j=1 Mj
n
M= ÕM
j=1
Среднее геометрическое
взвешенное
Среднее арифметическое
взвешенное
-
M=
j
1
n
1 n
å Mj
n j=1

1 n
M=
å M2
n j=1 j
Выбор аналитического метода определения весовых коэффициентов gj зависит от вида среднего взвешенного и других
115
причин. При числовом представлении базовых метрик Mj их
комплексирование с учетом весовых коэффициентов gj должно
проводиться в соответствии с правилами теории размерностей.
Удобнее комплексировать безразмерные метрики. Для этого от
шкал отношений переходят к абсолютным шкалам.
Для перехода к безразмерным метрикам Mjrel можно использовать соотношения
Mj
Mjrel =
ïðè Mj £ Mjn ;
Mjn
Mjrel =
Mjn
Mj
ïðè Mj > Mjn ,
где Mjn – нормирующее значение метрики, имеющее ту же размерность, что и Mj.
В качестве нормирующего значения Mjn можно принимать
значения соответствующих метрик эталонных образцов ПС. Аб=

 , M, M, M и т. д.)
солютные значения производных метрик ( M
получаются в этом случае безразмерными.
При разработке способов комплексного оценивания качества
ПС с учетом весомости свойств отдается предпочтение среднеарифметической взвешенной оценке благодаря простоте ее вычисления. Кроме вышеперечисленных способов комплексирования, различают еще один способ ранжирования по трехуровневой шкале. Его применяют в тех случаях, когда определение
числовых значений базовых метрик сложно и дорого. В этом случае экспертным методом определяют уровень базовых метрик:
высокий – В, средний – С, низкий – Н. При определении производной метрики в качестве исходной предпосылки принимают,
что при высоком уровне всех базовых метрик числовое значение
производной должно равняться 1, при среднем уровне – 0,5, при
низком – 0.
В этом случае значение производной метрики определяют по
формуле
 = 1 - nÍ - 0,5 nÑ ,
M
n
n
где nн и nс – число базовых метрик низкого и среднего уровня соответственно; n – число комплексируемых базовых метрик.
116
Если же весомости базовых метрик различны, тогда значение
производной метрики определяют по следующей формуле:
nÍ
nÑ
j=1
i=1
 = 1 - å g - 0,5å g ,
M
Íj
Ñi
где gÍ j и gÑi – нормированный вес базовой метрики низкого
и среднего уровня соответственно, а требования нормирования
сводятся к тому, чтобы сумма весов всех базовых показателей
равнялась единице.
В качестве примера весовые коэффициенты, учитывающие
влияние подхарактеристик на характеристики показателей качества модели внутреннего и внешнего качества стандарта ISO/
IEC 25000, приведены на рис. 41.
Для производных метрик низкие значения одних базовых
метрик могут компенсироваться высокими значениями других.
Иногда такая компенсация противоречит жизненным ситуациям. В то же время недопустимо компенсировать низкие значения
главных метрик высокими значениями второстепенных. Для исключения такой возможности производную метрику умножают
на так называемый коэффициент вето ϕ(Mj), например:


Mϕ = ϕ(Mj ) M,

где Mϕ – среднее взвешенное арифметическое с учетом коэффициента вето.
Коэффициент вето – это функция, которая при выходе любой
из важнейших базовых метрик за допустимые пределы обращается в ноль. Во всех остальных случаях коэффициент вето ϕ(Mj)
остается равным единице. Формально это записывается так:
ìï1, Mj £ Mj £ Mj
min
max
ϕ(Mj ) = ïí
.
ïï0, (Mj ³ Mj ) Ú (Mj £ Mj )
min
max
î
Из-за коэффициента вето производная метрика падает до
нуля, если значение хотя бы одной из важнейших базовых метрик оказывается неприемлемым.
Чувствительность к изменениям средних взвешенных
Субъективный характер выбора параметра логики усреднения при образовании производных метрик по принципу среднего
взвешенного ставит вопрос о том, какая разновидность среднего
117
118
›
¬½ÇºÊË»Ç
ÊÇÈÉǻǿ½¾ÆÁØ
ª s Êɾ½ÆØØÊ˾ȾÆÕ»ÄÁØÆÁØ
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Š›
ÈÉÇÁÀ»Ç½Á˾ÄÕ
ÆÇÊËÁ
¶Í;ÃËÁ»ÆÇÊËÕ ›
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
ɾÊÌÉÊÇ»
¨¾É¾ÆÇÊÁÅÇÊËÕ
¦ s ÆÁÀùØÊ˾ȾÆÕ»ÄÁØÆÁØ
™½¹ÈËÁÉ̾ÅÇÊËÕ ›
¬½ÇºÊË»Ç
ÌÊ˹ÆÇ»ÃÁ
¦
ªÈÇÊǺÆÇÊËÕ
¦
ªË¹ºÁÄÕÆÇÊËÕ
ÃÊÇÊÌÒ¾ÊË»Ç ›
¬½ÇºÊË»Ç
»¹ÆÁ×
ª
ÈÉÇ»¾ÉÃÁ
¬½ÇºÊË»ÇÀ¹Å¾ÆÔ ª
ªÇÇË»¾ËÊË»Á¾
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Š›
Ê˹ƽ¹É˹Š›
̽ǺÊË»¹
ȾɾÆÇÊÁÅÇÊËÁ
ÊÇÈÉǻǿ½¾ÆÁØ
™Æ¹ÄÁÀÁÉ̾ÅÇÊËÕ ›
›É¾Å¾ÆÆ¹Ø › ¬½ÇºÊ˻ǻƾʾÆÁØ
ÖÍ;ÃËÁ»ÆÇÊËÕ
ÁÀžƾÆÁ ª
¶Í;ÃËÁ»ÆÇÊËÕ
Рис. 41. Вес в модели качества стандарта ISO/IEC 25000
› s »ÔÊÇùØÊ˾ȾÆÕ»ÄÁØÆÁØ
¨ÉÁ»Ä¾Ã¹Ë¾ÄÕ ª
ÆÇÊËÕ
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Š›
̽ǺÊË»¹
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
¬½ÇºÊË»Ç
¦
ǺÌоÆÁØ
¬½ÇºÊË»ÇɹºÇËÔ ›
ª
¨ÇÆØËÆÇÊËÕ
¬ÊËÇÂÐÁ»ÇÊËÕ
¦
ÃÇËùÀ¹Å
¬½ÇºÊË»Ç
ÁÊÈÇÄÕÀÇ»¹ÆÁØ
¹»¾ÉѾÆÆÇÊËÕ ¦
¦¹½¾¿ÆÇÊËÕ
ªÈÇÊǺÆÇÊËÕ ›
ªÈÇÊǺÆÇÊËÕ
¦ ûÇÊÊ˹ÆǻľÆÁ×
ûÀ¹ÁÅǽ¾ÂÊË»Á×
ªÇÇË»¾ËÊË»Á¾
¹ÒÁÒ¾ÆÆÇÊËÕ ¦
Ê˹ƽ¹É˹Š›
ƹ½¾¿ÆÇÊËÁ
ªÇÇË»¾ËÊË»Á¾
Ê˹ƽ¹É˹Ũ§ ª
«ÇÐÆÇÊËÕ
­ÌÆÃÏÁÇƹÄÕƹØ
›
ÈÉÁ¼Ç½ÆÇÊËÕ
­ÌÆÃÏÁÇƹÄÕÆÇÊËÕ
›ÆÌËɾÆƾ¾Á
»Æ¾Ñƾ¾
ùоÊË»Ç
взвешенного предпочтительнее в конкретных условиях. Чтобы
ответить на поставленный вопрос, выбирают ряд признаков, по
которому ведут сравнение средних взвешенных. Один из таких
признаков – чувствительность к изменениям (приращениям значений каждой из базовых метрик Mj). Понятно, что чувствительность к изменениям определяет дифференциал средневзвешенной производной метрики:
æ
ö
¶M
¶ çç n
gj ÷÷
=
çç Õ Mj ÷÷;
¶Mj ¶Mj çè j=1
÷÷ø

æ
ö÷
¶M
¶ çç n
÷
g
M
=
ç å j j ÷÷;
÷ø÷
¶Mj ¶Mj ççè j=1
æ
n g ö÷

¶M
¶ çç
j ÷
÷;
=
1/
ç å
¶Mj ¶Mj ççè j=1 Mj ÷÷ø÷
=
æ
¶M
¶ çç
=
ç
¶Mj ¶Mj çèç
ö
2 ÷÷÷
g
M
å j j ÷÷÷.
j=1
ø
n
Для среднего арифметического взвешенного
æ
ö÷
çç n

÷÷
æ
ö÷
ç
¶M
¶ çç n
¶
÷
çç g M + g M ÷÷÷ = g
=
çç å gj Mi ÷÷ =
å i i j j ÷÷ j
¶Mj ¶Mj çè j=1
÷÷ø ¶Mj çççi=1
÷÷
çèi¹ j
ø÷
чувствительность к изменениям базовой метрики является величиной постоянной и равной весу этой метрики среди других. Для
среднего геометрического взвешенного
ææ
ö÷
ö
÷÷
÷÷
çççççç n
æ n
ö÷
÷
¶M
¶ çç
¶ çç
gj ÷
gi ÷÷ gj ÷÷
=
(3.12)
çç Õ M ÷ M ÷. çÕ M ÷ =
¶Mj ¶Mj ççè j=1 j ÷÷÷ø ¶Mj çççççi=1 i ÷÷÷ j ÷÷÷
ç
÷ø÷
÷ø÷
ççèèçi¹ j
Постоянный множитель обозначим
n
g
C = Õ Mi i .
i=1
i¹ j
Тогда формула (3.12) примет вид:
119
(
)
( )
¶M
¶
¶
g
g
g -1
=
CMj j = C
Mj j = CMj j .
¶Mj ¶Mj
¶Mj
Как видно из этой формулы, чувствительность к изменениям
базовой метрики среднего геометрического взвешенного зависит
от веса и от значения этой метрики.
Для среднего гармонического взвешенного
æ
n g ö÷

¶M
¶ çç
j ÷
÷.
=
1/
ç å
¶Mj ¶Mj ççè j=1 Mj ÷÷ø÷
n
gj
j=1
Mj
 = u-1, где u =
Полагая M
å
, имеем
æ n g ÷ö2

ç
¶M
j ÷
-2
÷÷ ,
= -1u = -1/ çç å
çç
M
¶u
è j=1 j ÷÷ø
æ
ö÷
ç
÷÷
æ
ö
¶u
¶ çç n gj ÷÷
¶ ççç n
-1
-1 ÷
-2
÷÷ =
=
ççå gi Mi + gj Mj ÷÷÷ = -gj Mj .
çç å
¶Mj ¶Mj çè j=1 Mj ÷÷ø ¶Mj ççi=1
÷÷
÷÷ø
çèi¹ j
Следовательно,
æ n g ÷ö2
æ n g ö÷2

 ¶u
çç
¶M
¶M
j ÷
j ÷
2 çç
-2
÷ g j Mj = g j / Mj ç å
=
×
= 1/ ç å
÷
÷÷ .
ç
ç
÷
¶Mj
¶u ¶Mj
çè j=1 Mj ÷ø
çè j=1 Mj ÷÷ø
Чувствительность к изменениям базовой метрики среднего
гармонического взвешенного также зависит от веса и от значения этой метрики.
Для среднего квадратического взвешенного
=
æ
¶M
¶ çç
=
ç
¶Mj ¶Mj çèç
ö÷
n
å gj M2 ÷÷÷÷÷. j
j=1
ø
Здесь имеем следующую цепочку зависимостей:
=
n
M = u1/2 , u = å gj M2 .
j=1
Тогда
120
j
(3.13)
=
¶ M 1 -1/2
= u
=1/ 2
¶u
2
n
å gj M 2 ,
j
j=1
æ
÷÷ö
çç n
æ
ö÷
÷
ç
¶u
¶ çç n
¶
2÷
2
2÷
=
çççå gi Mi + gj Mj ÷÷÷ = 2gj Mj .
çç å gj M j ÷÷ =
¶Mj ¶Mj çè j=1
÷÷
÷÷ø ¶Mj ççi=1
çèi¹ j
÷÷ø
Подставив полученные выражения в формулу (3.13), окончательно получим
=
=
¶ M ¶ M ¶u
=
×
= 2 g j Mj /
¶Mj
¶u ¶Mj
n
å gj M 2 .
j=1
j
В этом случае чувствительность к изменениям базовой метрики является также функцией от веса и от значения этой метрики.
В общем случае чувствительность к изменениям базовых метрик
является функцией вида

¶M
= f (gj , Mj ).
¶Mj
Модели качества ПС, вводящей множества характеристик и
подхарактеристик, наравне с отношениями между ними, изоморфна модель измерений ПС, в которой каждой (под)характеристике соответствует производная метрика. С целью формирования оценки качества ПС процесс комплексирования метрик
продолжается для получения значения каждой производной
метрики, соответствующей определенной (под)характеристике
модели качества.
3.1.2. Метрики качества программных средств
По определению современного стандарта ISO/IEC 25000,
мера – это переменная, которой в результате измерения присваивается определенное значение. Мы в качестве семантически
эквивалентного понятия «мера» в трактовке стандарта ISO/IEC
25000 будем использовать термин «метрика». Адаптируем определения стандарта ISO/IEC 25000, касающиеся базовой и производной мер.
121
Определение 49. Базовая метрика. Базовая метрика представляет собой метрику, определенную в терминах атрибута и метода
его обсчета. Базовая метрика является функционально не зависимой от других метрик.
Определение 50. Производная метрика. Производная метрика
является метрикой, которая определяется посредством функции
от двух или более значений базовых или других производных
метрик. Преобразование метрики с использованием математических функций также является производной метрикой.
Определения базовых метрик основано на графовой модели
ПС. Базовые метрики обсчитывают количество вершин, ребер
определенного типа и длину пути графа из ребер определенного
типа, используя свойство конечности множеств вершин V и ребер
E графовой модели ПС. На основе этих метрик путем комплексирования создаются производные метрики.
Определение 51. Метрика общего количества вершин. Функция vc:V→VT→  имеет в качестве области определения подмножество декартова произведения вершин и их типов, а в качестве области значений – подмножество натуральных чисел
vc(v,t)=|{v∈V:vt(v)=t}| vc(v,t) = {v Î V : vt(v) = t} .
Определение 52. Метрика общего количества ребер. Функция ec:E→ET→  имеет в качестве области определения подмножество декартова произведения ребер и их типов, а в качестве области значений – подмножество натуральных чисел
ec(e,r)=|{e∈E:et(e)=r}|.
Определение 53. Метрика количества входных ребер вершины. Функция iec:IEG→ET→  имеет в качестве области определения подмножество декартова произведения входных ребер IEG и
их типов для некоторой вершины, а в качестве области значений –
подмножество натуральных чисел iec(v,r)=|{e∈IEG(v):et(e)=r}|.
Определение 54. Метрика количества выходных ребер
вершины. Функция oec:OEG→ET→  имеет в качестве области определения подмножество декартова произведения выходных ребер OEG и их типов для некоторой вершины, а в качестве области значений – подмножество натуральных чисел
oec(v,r)=|{e∈OEG(v):et(e)=r}|.
Определение 55. Метрика количества входных вершин вершины. Функция ivc:IVG→VT→  имеет в качестве области определения подмножество декартова произведения входных вершин
122
IVG и их типов для некоторой вершины, а в качестве области значений – подмножество натуральных чисел ivc(v,t)=|{s(e)∈IVG(v):
vt(s(e))=t}|.
Определение 56. Метрика количества выходных вершин вершины. Функция ovc:OVG→VT→  имеет в качестве области определения подмножество декартова произведения выходных вершин
OVG и их типов для некоторой вершины, а в качестве области значений – подмножество натуральных чисел ovc(v,t)=|{s(e)∈OVG(v):
:vt(s(e))=t}|.
Определение 57. Метрика количества входных вершин вершины с ребрами определенного типа. Функция ivec:IVG→VT→ 
→ET→  имеет в качестве области определения подмножество
декартова произведения входных вершин IVG, их типов и типов
ребер для некоторой вершины, а в качестве области значений –
подмножество натуральных чисел ivec(v,t,r)=|{(t(e):e∈IVG(v))∧ 
∧(vt(s(e))=t)∧(et(e)=r)}|.
Определение 58. Метрика количества выходных вершин
вершины с ребрами определенного типа. Функция ovec:OVG→ 
→VT→ET→  имеет в качестве области определения подмножество декартова произведения выходных вершин OVG, их типов и типов ребер для некоторой вершины, а в качестве области значений – подмножество натуральных чисел ovec(v,t,r)=
=|{(s(e):e∈OVG(v))∧(vt(t(e))=t)∧(et(e)=r)}|.
Определение 59. Метрика длины нисходящего пути вершины из ребер определенного типа. Функция ipath : IVGn ® VT ®
® ET ®  имеет в качестве области определения подмножество декартова произведения входных вершин IVGn , имеющих зависимость n-го порядка с данной, их типов и типов
ребер для некоторой вершины, а в качестве области значений – подмножество натуральных чисел ipath(v,t,r ) =
= {(t(e) : e Î IVGn (v)) Ù (vt(s(e)) = t) Ù (et(e) = r)} .
Определение 60. Метрика длины восходящего пути вершины из ребер определенного типа. Функция opath : OVGn ® VT ®
® ET ®  имеет в качестве области определения подмножество декартова произведения выходных вершин OVGn ,
имеющих зависимость n-го порядка с данной, их типов и типов ребер для некоторой вершины, а в качестве области значений – подмножество натуральных чисел opath(v,t,r ) =
= {(s(e) : e Î OVGn (v)) Ù (vt(t(e)) = t) Ù (et(e) = r)} .
123
Каждая производная метрика определяются путем введения
функциональной зависимости от n (n>0) других, как базовых,
так и производных метрик. Основными видами функциональных
зависимостей, порождающих производные метрики, являются:
– сумма n базовых (производных) метрик;
– частное от деления одной базовой (производной) метрики на
другую;
– среднее значение базовых (производных) метрики (арифметическое, геометрическое и т. п.);
– максимальное значение базовой (производной) метрики;
– минимальное значение базовой (производной) метрики.
3.1.3. Метрические пространства
Выше было раскрыто смысловое значение термина «метрика».
Для введения формальной модели измерений следующее определение раскрывает математический смысл термина «метрика».
Определение 61. Метрика. Отображение d:X2→R+ называют
метрикой на X, если:
1) d(x,y)=0⇔x=y,
2) d(x,y)= d(y,x),
3) d(x,y)≤d(x,z)+d(z,y)
при x,y,z∈X x, y, z Î X.
Вместе с графовыми моделями, представляющими множество
ПС, которые обладают одинаковой функциональностью, но отличаются структурой, базовые, наравне с производными метриками, образуют метрические пространства.
Определение 62. Метрическое пространство. Пару (X,d) называют метрическим пространством. Вещественное число d(x,y)
именуют расстоянием между x и y. В однозначном контексте
допустимо само множество X называть метрическим пространством.
Отображение d:X2→R+ является метрикой в том и только в
том случае, если:
1) {d≤IX},
2) {d≤t}={d≤t}–1,
3) {d≤t1}°{d≤t2}⊂{d≤t1+ t2},
при t1,t2∈R+.
Пусть (X1,d1) и (X2,d2) – метрические пространства и
X=(X1×X2). Для x = (x1, x2 ) и y = (y1, y2 ) положим d(x, y ) =
= d1 (x1, y1 ) + d2 (x2 , y2 ). Тогда d – метрика на X.
124
Значения базовых метрик являются оценками количества
вершин (ребер) определенного типа. Они представляют собой
дискретные метрики, метрические пространства, которые они
образуют, являются дискретными. Производные метрики образуют метрические пространства различной природы.
Определение 63. Базовые метрические пространства. Базовыми называются счетные дискретные метрические пространства Mb. Образующие множества представляют собой графовые
модели ПС. Метриками являются количественные свойства графовых моделей, оценивающие количественные величины элементов графа определенного типа.
Определение 64. Производные метрические пространства.
Производными называются метрические пространства Md, элементами которых являются графовые модели ПС, а метриками –количественные свойства графовых моделей, полученные
на основе вычислений n-местных функций (n>0), аргументами
которых являются как базовые, так и производные метрики.
Производные метрики, в зависимости от функциональных зависимостей, на основе которых они построены, могут образовывать метрические пространства, обладающие разными свойствами. Далее приводятся необходимые для дальнейшего изложения
сведения из функционального анализа, описывающие свойства
метрических пространств.
Определение 65. Векторное пространство. Модуль X над полем вещественных чисел  является вещественным векторным
пространством. Элементы  называют скалярами, а элементы
X – векторами. Полная запись вещественного векторного пространства выглядит так: (X,  ,+,⋅). Будет использоваться и сокращенная запись, состоящая в отождествлении множества векторов X с отвечающим ему векторным пространством.
Для идентификации программных дефектов необходимо задавать границы значений метрик, таким образом будет получаться
подпространство метрического пространства.
Определение 66. Подпространство векторного пространства.
Векторное пространство (X0,  ,+,⋅) является подпространством
векторного пространства (X,  ,+,⋅), если X0 – подгруппа в X и
умножение на скаляр в X0-сужение на  ×X0-умножения на скаляр в X. Множество X0 называют линейным множеством в X.
Оценивание ПС по нескольким метрикам будет приводить к
образованию произведения метрических пространств.
125
Определение 67. Произведение векторных пространств. Пусть
(Xk)k∈K – семейство векторных пространств над полем , k – ин-
дексы из множества индексов K. Пусть X = Õ kÎK Xk – произведение соответствующих множеств, т. е. совокупность отображений x : K ® ∪ kÎK Xk , для которых xk=x(k)∈Xk при каждом k∈K
(при K≠∅). Наделим X покоординатными операциями сложения
и умножения на скаляр:
(x1+x2)(k)= x1(k)+x2(k) при x1+x2∈X, k∈K;
(λ⋅x)(k)=λ⋅x(k) при x∈X, λ∈ , k∈K.
Полученное векторное пространство X над  называют произведением векторных пространств (Xk)k∈K. При K={1,2,…,n}
пишут X1×X2×…×Xn=X. В случае, когда Xk=X для любого k∈K,
используют обозначение XK=X. Если к тому же K={1,2,…,n}, используют обозначение Xn=X.
N-мерное метрическое пространство, образуемое производной
метрикой, может быть разложено на составляющие пространства с целью упрощения анализа свойств самого пространства и
определенных на нем операторов преобразований. Для этого вводится понятие суммы пространств.
Определение 68. Прямая сумма векторных пространств. Подпространства X1 и X2 векторного пространства X разлагают X
в (алгебраическую) прямую сумму, X=X1⊕X2, если X1∧X2=0 и
X1∨X2=X. При этом X2 называют (алгебраическим) дополнением X1, а X1 – (алгебраическим) дополнением X2.
Понятие координатной проекции используется в тех случаях,
когда необходимо работать с одним из пространств, составляющих n-мерное метрическое пространство.
Определение
69.
Координатная
проекция.
Пусть
X = Õ kÎK Xk – произведение семейства векторных пространств
(Xk)k∈K. Отображение Prk:X→Xk, определяемое соотношением
Prk(x)=xk, называют координатной проекцией, при этом Prk является линейным оператором Prk∈L(X,Xk).
Задача оценивания значений метрик в n-мерном пространстве,
поиска дефектных или эталонных областей в этом пространстве
при больших значениях n является сложной как в вычислительном плане, так и в случае необходимости визуального отображения этой информации для оценивания экспертами. Одной из
возможностей снижения n является поиск базиса метрического
пространства.
126
Определение 70. Линейная независимость в векторных пространствах. Конечное множество S в X называют линейно независимым, если из условия å sÎS λ s s = 0, где λs∈R, следует, что
λs=0 для всех s∈S. Множество S называют линейно независимым,
если любое конечное подмножество S линейно независимо.
Определение 71. Алгебраический базис в векторных пространствах. Максимальное по включению линейно независимое
множество в X называют алгебраическим базисом (базисом Гамеля). Любое линейно независимое множество содержится в некотором алгебраическом базисе. У всех таких базисов одинаковая
мощность, называемая размерностью X и обозначаемая dim X.
Каждое векторное пространство X изоморфно прямой сумме семейства (R)k∈K, где K имеет мощность dim X. Если X1 – подпространство X, то размерность X/X1 называют коразмерностью X1
и обозначают codim X1. Если X=X1+X2, то codim X1=dim X2 и
dim X=dim X1+codim X1.
3.1.4. Операторы комплексирования
На базовых (Mb) и производных (Md) метрических пространствах вводится множество операторов для формального описания процесса комплексирования производных метрик из других
производных и базовых, они называются операторами комплексирования.
Определение 72. Операторы комплексирования. Операторы
комплексирования Ac:Mb→Md, Ac:Md→Md отражают зависимости одних производных метрик от других производных или базовых. В зависимости от способов комплексирования операторы Ac
могут иметь различную природу, быть линейными, нелинейными, ограниченными, непрерывными и т. п.
Ниже приводятся основные свойства операторов комплексирования, определяемых на метрических пространствах.
Определение 73. Линейный оператор. Соответствие W⊂X×Y,
где X, Y – векторные пространства, называют линейным,
если W – линейное множество в произведении векторных пространств X×Y. Отображение W:X→Y, являющееся линейным
соответствием, называют линейным оператором. Отображение
W:X→Y является линейным оператором в том и только в том
случае, если выполнено W(λ1x1+λ2x2)= λ1Wx1+λ2Wx2, где λ1,
λ2∈R, x1+x2∈X.
Множество L(X,Y) всех линейных операторов из X в Y представляет собой векторное пространство – подпространство YX.
127
Определение 74. Изоморфизм. Линейный оператор W∈L(X,Y)
называют (алгебраическим) изоморфизмом, если соответствие
W–1 является линейным оператором из L(Y,X).
Определение 75. Ядро, коядро и кообраз линейного оператора. Для оператора W∈L(X,Y) определяется ker W=W–1(0) – ядро,
coker W=Y/im W – коядро (im W – образ), coim W=X/ker W – кообраз W. Оператор W называют мономорфизмом, если ker W = 0,
эпиморфизмом, если im W = Y. Оператор является изоморфизмом в том и только в том случае, если он является мономорфизмом и эпиморфизмом одновременно.
3.1.5. Категория измерений
Метрические пространства совместно с операторами комплексирования образуют категорию измерений.
Определение 76. Категория измерений. Категория MS, объектами которой являются метрические пространства Mb и Md, а
морфизмами – операторы комплексирования Ac, называется категорией измерений.
Лемма 6. Категория измерений является малой категорией.
Доказательство. По построению, в соответствии с определением, объекты категории измерений образуют конечное множество. Отсюда следует, что категория измерений является малой.
Лемма 7. Морфизм u:X→Y в MS является мономорфизмом,
если и только если он инъективен.
Доказательство. Любое инъективное отображение u является мономорфизмом, так как из u(f(z)) = 0 для любых z∈Z, следует
f(z) = 0. Пусть u является мономорфизмом, Z = ker u=|x∈X:u(x)=0|,
f:Z→X – включающее отображение. Тогда u°f = 0, и поэтому f =
0, из чего следует, что Z = ker u = 0, т. е. u инъективен.
Лемма 8. Морфизм u:X→Y в MS является эпиморфизмом,
если и только если u(X) плотно в Y.
Доказательство. Если для u имеется плотный образ в Y
и f°u=0, тогда f отражается в ноль на плотном подмножестве
u(X)⊆Y и в силу непрерывности f≡0.
Пусть u:X→Y является эпиморфизмом, u (X) – замыкание
Y
u(X), f : Y ®
– каноническая проекция. Тогда f⋅u=0, и поu ( X)
этому f=0, что означает, что u (X) = Y.
Морфизм u:X→Y является изоморфизмом, если существует
морфизм z:Y→X, такой, что z⋅u=1X и u⋅z =1Y.
128
Лемма 9. Изоморфизмы в MS являются сюръективными изометриями.
Доказательство. Лемма непосредственно следует из теоремы
об открытых отображениях.
В дальнейшем будем считать, что метрические пространства
X и Y изоморфны, если между ними существует изометрия.
Для любого морфизма в MS существует каноническая декомпозиция:
9
:
V


V
9 V V 9
Здесь ρ = coim u – отношение отображения X в
X
и
u (0)
ι = im u – изометрическое встраивание подпространства u (X)
в пространство Y.
Морфизм u, для которого u является изоморфизмом, называют точным морфизмом.
Определение 77. Предельный мономорфизм. Морфизм u:X→Y
в MS называется предельным, если u=m°e, где m – мономорфизм,
а e – эпиморфизм, из чего следует, что e – изоморфизм.
Лемма 10. Морфизм u:X→Y в MS является предельным мономорфизмом, если и только если он строгий мономорфизм.
Доказательство. Пусть u:X→Y – строгий мономорфизм, т. е.
изометрическое встраивание, и пусть u=m°e. Тогда ||x||=||u(x)||=||
m(e(x))||≤||e(x)|| ≤||x|| для всех x∈X, т. е. e – изометрия с плотным
отображением и поэтому является изоморфизмом. С другой стороны, пусть u – предельный мономорфизм и u = ι  u  ρ – каноническая декомпозиция. Тогда u = (ι  u)  ρ, следовательно, ρ – изометрический изоморфизм, т. е. тождество на X. Следовательно,
u = ι  u, из чего следует, что u – изоморфизм, т. е. u – строгий
мономорфизм.
Лемма 11. Морфизм u:X→Y в MS является предельным эпиморфизмом, если и только если он точный эпиморфизм.
Доказательство. Пусть u:X→Y – строгий эпиморфизм, т. е.
фактор-отображение, и пусть u=m°e. Пусть Z=u-1(0). Тогда
-1
inf x + z = u(x) = m(e(x)) £ e(x) £ e(x + z) £ x + z
zÎZ
129
для всех z∈Z. Следовательно, ||m(e(x))||=||e(x)|| для всех x, т. е. m –
изометрия, которая является сюръективной, так как u сюръективен. С другой стороны, пусть u – предельный эпиморфизм и
u=ι°u°ρ – каноническая декомпозиция. Тогда ι – изоморфизм,
т. е. u(X) = Y. Поэтому u = u  ρ, из чего следует, что u – изоморфизм, что означает, что u – точный эпиморфизм.
Произведения. Пусть (Xk)k∈K – семейство метрических пространств над полем R в MS, Õ kÎK Xk – их произведение. Семейство морфизмов (πk)k∈K определяется следующим образом:
π k : Õ kÎK Xk ® Xk , причем для любых метрического пространства Z и семейства (ϕk)k∈K морфизмов ϕk:Z→Xk существует единственный морфизм ϕ = Õ kÎK ϕk : Z ® Õ kÎK XK , такой, что диаграмма является коммутативной:
9L
P
L Î,
J
RL
9L
JL
;
Лемма 12. Для любого семейства (Xk)k∈K в категории MS существует произведение Õ kÎK Xk в MS, которое является (изометрично изоморфно) пространством (пространству) всех таких
элементов x=(xk)k∈K, xk∈Xk, что x ¥ = sup xk X < ¥. МорфизkÎK
k
мы πk являются проекторами πk(x)=xk на k-координату. Каждый
πk представляет собой фактор-оператор.
Доказательство. Пусть ϕk:Z→Xk – семейство морфизмов.
Существование ϕ : Z ® Õ kÎK Xk влечет πk(ϕ(z))=ϕk(z), т. е.
ϕ(z)=ϕk(z). Более того, выполняется ϕ = sup ϕk .
k
Прямые суммы. Прямая сумма в категории MS семейства
(Xk)k∈K метрических пространств представляет собой метрическое пространство å kÎK Xk вместе с семейством (ιk)k∈K морфизмов ιk : Xk ® å kÎK Xk , таких, что для каждого члена семейства
морфизмов (ϕk)k∈K, ϕk:Xk→Z существует единственный морфизм
ϕ : å kÎK Xk , такой, что диаграмма является коммутативной:
130
9L
3 9L
ML
L Î,
J
JL
;
Лемма 13. Для любого семейства (Xk)k∈K в категории MS существует сумма å kÎK Xk в MS, которая является (изометрична
изоморфна) пространством (пространству) всех таких элементов
x=(xk)k∈K, xk∈Xk, что x 1 = å kÎK xk X < ¥.
k
Доказательство. Пусть ϕk:Z→Xk – семейство морфиз-
мов. Существование ϕ : å kÎK Xk ® Z влечет ϕk(ιk(xk))=ϕk(xk),
т. е. ϕ(xk ) = å kÎK ϕk (xk ). Более того, выполняется
=
å kÎK ϕk (xk ) £ å kÎK ϕk
xk
Xk
£ å kÎK xk
Xk
ϕ(xk ) =
= x 1 , и соот-
ветствующая диаграмма коммутирует.
Определение 78. Модель измерений ПС. Модель измерений
ПС представляет собой подкатегорию категории измерений MS,
в которую, в соответствии с целями моделирования, включаются метрические пространства Mb, Md и операторы комплексироE
.
D
" .
"
D
"
E
E
.
.
EO
E
Q
DOsOs
" EOs
.
DOOs
.
"
D
Q
"
DOOs
DOOs
.
EO
.
"
"
.
EO
"DO
U s
E O DOOs
" .
EO
DOOs
.
EO
E Os
S
.
" DOOs
UsS
EO
Us
.
DOOs
" US
.
EO
U
Рис. 42. Схема модели измерений
131
вания Ac, входящие в классы объектов и морфизмов категории
MS.
На рис. 42 представлена структурная схема модели измерений.
В модели измерений, в отличие от модели качества, морфизмы имеют противоположное направление, образуя коконусы.
Таким образом, выявляется назначение модели измерений –
фиксировать метрические пространства для оценивания концептуальных понятий качества и определять функциональные зависимости для порождения значений производных измерений,
соответствующих верхним уровням иерархии за счет комплексирования измерений, соответствующих нижним.
3.1.6. Функтор из категории качества в категорию измерений
Категория качества Q предназначена для представления в формальном виде модели качества программ. Категория измерений
MS служит моделированию определения измеримых характеристик программного обеспечения. С целью связи категории качества и категории измерений определим функтор QM:Q→MS.
Определение 79. Функтор из категории качества в категорию
измерений. Функтор QM:Q→MS является контравариантным
одноместным функтором, отображающим объекты категории
качества (характеристики, подхарактеристики, принципы проектирования) на метрические пространства категории измерений (базовые и производные) QM(Ob(Q))=Ob(MS), а морфизмы
категории качества – на морфизмы категории измерений, являющимися операторами над метрическими пространствами
QM(Mor(Q))=Mor(MS).
Функтор QM:Q→MS на объектах категории Q задается следующим образом.
1. На объектах:
1) QM (∪ iÎ{0,n-1} {q i }) = ∪ iÎ{0,n-1} { M di } – отображение элементов категории качества, отвечающих за представление производных измерений, подхарактеристик и характеристик на производных метрических пространствах.
2. На морфизмах:
1) на морфизмах, принадлежащих парам соседних уровней:
1,i
ci,i-1
ci,i-1
QM (ξis,m ) = A m,s , i∈{1,…,n}, где A m,s – оператор, опреdi
деленный на X Í M m , имеющий в качестве области значений
i
Y Í M dis-1, соответствующих элементам qm
и qsi-1;
132
133
q1
n
1n,1-1,n
qn1 -1
...
n
q2
1,n
1n,2
q11
0,1
q3n
1,n
 2n,3
...
.
q21
n
...
0,1
1, p
q5n
1,n
 2n,5
 12,,nt-1
 2n,-4 1,n
q4
qn2 -1
0,1
1,2
2n,1- 1,n - 1
1,1
0
q1
...
qnr -1
...
s,m
m ,s
M
dn
1
M
dn
2
Acn2,,1n -1
M dn3
,n -1
Acn
3 ,2
- 1, n- 1
Acn
1,2
Рис. 43. Функтор оценивания качества
qtn
Acn1,,1n -1
Mdn1-1
...
d1
{ Mdi } M 1
i Î { 0,n - 1}
1,i
ci,i - 1
QM (  is,m ) = A m ,s
i ,j

QM(  ) = A cj,i
{ qi }) = 
i Î { 0,n - 1}
1,n QM(  i,i ) = A ci,i
 nr ,s,m
m ,s
t
QM(
q tn- 1
1,n
 nr ,t -1
1
qp
Ac11,,10
d1
c 1,0
p ,1
...
, n -1
Acn
t,r
Mdnt-1
Mdnt
Mdnr-1
...
Md 1p
1
Acnt-, n1,r
Acnt-,11,2
...
A
dn-1
2
Acn5,,2n -1
,n -1
Acn
4,2
dn
M dn5
M 4
M
M 2
..
...
Ac12,,01
M d10
2) на морфизмах, принадлежащих уровням i, j при j>i+1:
QM (ξ i,j ) = A cj,i , i∈{0,…,n–2}, j∈{2,…,n},
s,m
m,s
где A cjm,i,s – оператор, определенный на X Í M djm , имеющий в качестве области значений Y Í M dis , соответствующих элементам
j
qm
и qsi ;
3) на морфизмах, принадлежащих одному уровню:
i
QM (ξsi,,m
) = A cim,i,s , i∈{1,…,n},
где A cim,i,s – оператор, определенный на X Í M dim , имеющий в качестве области значений Y Í M dis , соответствующих элементам
i
qm
и qsi .
На рис. 43 схематично показано действие функтора QM.
С помощью функтора QM на основе модели измерений MS
можно количественно оценить элементы модели качества Q, сделать это как для конкретной характеристики, подхарактеристики, принципа проектирования, так и для качества ПС в целом.
3.1.7. Квантификация принципов проектирования
программных средств
С помощью определенных базовых и производных метрик
происходит количественное оценивание концептуальных элементов модели качества. В общем случае численное оценивание
таких концепций, как, например, «переносимость» или «тестируемость», является нетривиальной задачей. Достаточно сложно подобрать метрики, значения которых свидетельствовали бы
о хорошей или плохой «переносимости» или «тестируемости».
В качестве посредников между определяемыми известными
стандартизованными моделями качества целесообразно использовать принципы проектирования. В отличие от характеристик и
подхарактеристик модели качества, принципы проектирования
являются контекстно-зависимыми понятиями, отражающими
основные подходы к решению задач на определенных парадигме
и языке программирования. Принципы проектирования основываются на опыте, накопленном при разработке успешных проектов разных масштабов с использованием определенной парадигмы программирования (например, процедурной, функциональной, объектно-ориентированной). Представить набор метрик,
отражающих качество ПС в смысле соответствия принципам
проектирования, оказывается значительно легче. С другой стороны, оценить характеристики модели ПС также проще исходя
134
из известных свойств принципов проектирования. Квантифицированные принципы проектирования могут быть инкапсулированы в модель качества как посредники между показателями
высокого уровня и конкретными метриками.
Значение, которое оказывают на качество ПС систематизированное применение определенных принципов проектирования,
стало предметом многих исследований [94–98]. Многие авторы
пытались синтезировать положительный опыт проектирования
[97–103], другие основное внимание уделяли отрицательным –
рефакторингу [93], антипаттернах [104] и дефектам [109]. Авторы этих исследований формулируют принципы проектирования
на разных уровнях – от точного, например, «класс не должен содержать более 6-ти объектов», до неопределенного «необходимо
избегать централизации управления» [98]. Подобная разобщенность затрудняет согласованное и систематизированное применение этих принципов. Зачастую те принципы, которые удается
сформулировать только на абстрактном уровне, оказывают большее влияние на качество, чем точно формулируемые.
Под квантификацией принципов проектирования понимается следующая совокупность процессов:
1) формирование базовых метрических пространств – выбор
множества базовых и производных метрик, влияющих на принцип проектирования;
2) определение эталонных значений – выбор интервалов значений множества базовых и производных метрик, при соблюдении которых не происходит нарушения принципа проектирования;
3) построение метрического пространства принципа проектирования – построение производного метрического пространства
на основе аналитического выражения над множеством метрик;
4) формирование эталонного и дефектного подпространств –
определение эталонных и дефектных интервалов значений производной метрики, выражающей принцип проектирования.
В основном эти четыре шага являются результатом экспертной работы. Учитываются хорошо зарекомендовавшие практики, накопленный опыт разработчиков. Квантифицированные
таким образом принципы проектирования затем нуждаются в
уточнении. Для этого создаются репозитории проектов, позволяющие на основе статистики и применения методов оптимизации
уточнить выбор метрик, добиться более правильных значений
формул и скорректировать эталонные интервалы.
135
С помощью квантифицированных принципов проектирования
производится фильтрация кода (модели), целью которой может
быть не только поиск дефектов, но и другие задачи, например,
поиск фрагментов кода, подлежащих повторному использованию, поиск шаблонов проектирования в коде, поиск фрагментов
кода для рефакторинга.
С целью поиска фрагментов кода, обладающих определенными свойствами, для базовых и производных метрик устанавливаются фильтры критических значений: m∈[x,y], m∉[x,y], m>x
(<,≤,≥). Для каждого фильтра посредством комплексирования
базовых и производных показателей определяется новая производная метрика с фиксированным набором допустимых или недопустимых значений.
Следует отметить, что качество квантификации принципов
проектирования зависит как от набора метрик, так и от правильно выбранного диапазона их значений. В качестве механизмов
оптимизации диапазонов значений метрик целесообразно применение алгоритмов оптимизации и систем самообучения.
Приведем пример квантификации принципов проектирования. Будем использовать такие принципы объектно-ориентированного проектирования, как «увеличение сцепления»,
«уменьшение связности», «отсутствие классов-данных» и «отсутствие классов-монстров».
Увеличение сцепления
Сцепление – это степень использования методами класса методов и атрибутов того же класса. При высоком сцеплении обязанности класса тесно связаны между собой, класс в большей
мере концептуально монолитен. Класс с низкой степенью сцепления выполняет разнородные действия и не связанные между собой обязанности, концептуально разобщен. «Увеличение
сцепления» – это принцип проектирования, согласно которому
каждый класс должен моделировать одно концептуальное понятие и стремиться к внутренней целостности. В табл. 13 приведены метрики для квантификации этого принципа проектирования, их семантические и формальные описания и допустимые интервалы.
Для оценивания того, насколько класс соответствует принципу «увеличение сцепления», введем следующую формулу над
указанными метриками:
136
µ1 =
3µ LCOM + µ NMWA
.
4
Затем определим эталонный интервал – [0,100, ¥ ]. Если для
некоторого класса выполняется µ1∈[0,100, ¥ ], то будем считать, что структура класса соответствует принципу проектирования «увеличение сцепления».
Таблица 13
Формулы расчета метрик уровня класса
Метрика
Формула
Количество
1 ,m2 Î{ s(e)ÎIVG (v): {m }
µ PP = å m
2
vt(s(e))= Me}Ù
пар методов,
OVG (m1 )ÇOVG (m2 ) =1
которые не используют общие
поля класса (PP)
Количество пар
ivec(f, Me, ac)!
f Î{s(e)ÎIVG (v):
методов, кото- µ QP = å vt
2 !(ivec(f, Me, ac) - 2)!
(s(e))=Va}
рые используют
общие поля
класса (QP)
Количество
{m Î {s(e) Î IVG (v) : vt(s(e)) = Me}
методов класса, µ NMWA =
Ù OVG (m) = 1}
которые не используют поля
класса (NMWA)
Количество
µ LCOM = µ PP - µ QP
пар методов,
которые не используют общие
поля класса, минус количество
пар методов, которые используют общие поля
класса (LCOM)
Допустимый
интервал
[0,000,
1,000]
[0,333,
¥]
[0,000,
0,333]
[0,000,
¥]
Уменьшение связности
При оценке степени связности учитываются все взаимодействия
классов (ассоциация, агрегация, композиция), которые рассматриваются как обмен сообщениями. Связность характеризует методы данного класса, которые используют операции или свойства
137
другого класса. Увеличение связности снижает способность класса к повторному использованию и усложняет его модификацию
и тестирование. Уменьшение связности улучшает модульность и
повышает инкапсуляцию ПС. В табл. 14 приведены метрики для
квантификации этого принципа проектирования, их семантические и формальные описания и допустимые интервалы.
Таблица 14
Формулы расчета метрик уровня класса
Метрика
Формула
Допустимый
интервал
Количество классов, которые использует данный
класс (NR)
Количество
классов, которые используют
данный класс,
при условии, что
и данный класс
использует эти
классы (NBR)
Количество
использований
абстрактного
предка данного
класса, разделенное на количество использований данного
класса непосредственно (NABR)
Количество классов, которые используют данный
класс (NAR)
Количество
классов, которые используют
абстрактного
предка данного
класса (NRA)
µ NR = ovec(v, Cl,us)
[2,000, ¥ ]
{s(e) : e Î OVG (v) Ù
vt(t(e)) = Cl Ù et(e) = us} ∩
µ NBR =
,
{t(e) : e Î IVG (v) Ù
vt(s(e)) = Cl Ù et(e) = us}
ãäå OVG (v) = {s(e) : e Î { EG : t(e) = v}},
IVG (v) = {t(e) : e Î { EG : t(e) = v}}
[0,333, ¥ ]
138
ivec(v, Cl, in)
ivec(v, Cl,us)
[1,000, ¥ ]
µ NAR = ivec(v, Cl,us)
[1,000, ¥ ]
µ NRA = ivec(v, Cl, in)
[0,100, ¥ ]
µ NABR =
Для оценивания того, насколько класс соответствует принципу «уменьшение связности», введем следующую формулу над
указанными метриками:
µ2 =
µ NR + µ NAR + 2µ NBR + 2µ NABR
.
6
Затем определим эталонный интервал – [1,000, 3,000]. Если
для некоторого класса выполняется µ2∈[1,000, 3,000], то будем
считать, что структура класса соответствует принципу проектирования «уменьшение связности».
Отсутствие классов-данных
«Классы-данные» – это классы, использующиеся только в
качестве структур данных для методов других классов. Наличие классов-данных, как правило, свидетельствует об ошибках
проектирования, так как каждой моделируемой сущности предметной области должно быть свойственно какое-то поведение.
Лишение класса поведения приводит к тому, что реализовывать
динамические свойства моделируемой этим классом концепции приходится другим классам. Отсюда происходит нарушение принципа, согласно которому одной концепции предметной области должен соответствовать один класс, отражающий
как статические, так и динамические свойства этой концепции.
В табл. 15 приведены метрики для квантификации этого принципа проектирования, их семантические и формальные описания и допустимые интервалы.
Для оценивания того, насколько класс представляет собой
класс-данное, введем следующую формулу над перечисленными
метриками:
µ
+ µ NOP + 2µ WMC
µ3 = WOC
.
4
Таблица 15
Формулы расчета метрик уровня класса
Метрика
Формула
Допустимый
интервал
Количество «функциональных»
общедоступных
методов (WOCF)
µ WOCF = ivc(v, Me) - ivc(v, Ge)
[2,000,
10,000]
139
Окончание табл. 15
Метрика
Формула
Количество общеµ WOCM = ivc(v, Me)
доступных методов
(WOCM)
Количество «функivc(v, Ge)
µ WOC = 1 циональных»
ivc(v, Me)
общедоступных
методов, разделенное на количество
общедоступных
методов (WOC)
Количество общеµ NOPA = ivc(v, Va)
доступных полей
(NOPA)
Количество геттерµ NOA = ivc(v, Ge)
или сеттер-методов
(NOA)
Количество общеµ NOP = ivc(v, Va) + ivc(v, Ge)
доступных полей
плюс количество
геттер- или сеттерметодов (NOP)
Цикломатическая
µ MC = max(ipath(me, Lo, co))
сложность метода
класса (MC)
Взвешенное колиµ WMC =
чество методов –
Î{s(e)ÎIVG (v): max(ipath(me, Lo, co))
сумма цикломати- = å m
vt(s(e))= Me}
ческих сложностей
всех методов класса (WMC)
Допустимый
интервал
[3,000,
10,000]
[0,500,
1,000]
[0,500,
1,000]
[2,000,
10,000]
[2,500,
11,000]
[0,100,
2,000]
[0,100,
4,000]
Затем определим эталонный интервал – [1,000, 2,000]. Если
для некоторого класса выполняется µ3∈[1,000, 2,000], то будем
считать, что класс не является классом-данным.
Отсутствие классов-монстров
«Класс-монстр» – это большой и сложный класс, который мало
зависит от остальных классов и предоставляет им мало функциональности. Как правило, такому классу соответствует несколько
концепций предметной области или некоторый набор статических и/или динамических свойств множества концепций. Такой
класс также нарушает принцип «одна концепция предметной об140
ласти – один класс». Классы-монстры трудны для восприятия,
их трудно тестировать и модифицировать. В табл. 16 приведены
метрики для квантификации этого принципа проектирования,
их семантические и формальные описания и допустимые интервалы.
Для оценивания того, насколько класс представляет собой
класс-монстр, введем следующую формулу над перечисленными
метриками:
µ
+ 3µ ATFD + µTCC
µ4 = WMC
.
5
Таблица 16
Формулы расчета метрик уровня класса
Обозначение
Формула
Допустимый
интервал
Количество пар
ivec(f, Me, ac)!
[0,333, ¥ ]
f Î{s(e)ÎIVG (v):
методов, кото- µ QP = å vt
2 !(ivec(f, Me, ac) - 2)!
(s(e))=Va}
рые используют
общие поля
класса (QP)
Цикломатиче[0,100,
µ MC = max(ipath(me, Lo, co))
ская сложность
2,000]
метода класса
(MC)
Взвешенное
[0,100,
µ WMC =
количество
4,000]
= å mÎ{s(e)ÎIVG (v): max(ipath(me, Lo, co))
методов – сумvt(s(e))= Me}
ма цикломатических сложностей всех
методов класса
(WMC)
Количество
[0,100,
µ ATFD = å mÎ{s(e)ÎIVG (v): {OVG (m)} / { IVG (v)}
vt(s(e))= Me}
полей независи2,000]
мых классов, к
которым обращаются методы
данного класса
(ATFD)
Количество
[1,000,
µ NM = ivc(v, Me)
методов класса
10,000]
(NM)
141
Окончание табл. 16
Обозначение
Формула
Крепость сцепления класса –
относительное
число пар
методов класса,
которые получают доступ
к как минимум
одному и тому
же полю этого
класса (TCC)
µTCC =
µ QP
Допустимый
интервал
[0,010, ¥ ]
µ NM
Затем определим эталонный интервал – [0,010, 1,000]. Если
для некоторого класса выполняется µ4∈[0,010, 1,000], то будем
считать, что класс не является классом-монстром.
3.2. Алгоритм оценивания качества программных средств
3.2.1. Стандарты оценивания качества
программных средств
Стандарт ISO/IEC 14598
Международный стандарт ISO/IEC 14598-1-6:1998-2001
[98–103] посвящен методологии оценивания характеристик
качества ПС на различных этапах жизненного цикла. Если задачей стандарта ISO/IEC 9126 являлось создание основы для
моделирования качества, то стандарт ISO/IEC 14598 образует
основу для оценивания качества. Стандарт содержит следующие части:
– ISO/IEC 14598-1. Общее описание;
– ISO/IEC 14598-2. Планирование и управление;
– ISO/IEC 14598-3. Процесс для разработчиков;
– ISO/IEC 14598-4. Процесс для покупателей;
– ISO/IEC 14598-5. Процесс для оценщиков;
– ISO/IEC 14598-6. Документация модулей оценивания.
На рис. 44 приведена взаимосвязь этих стандартов.
Предлагаемая стандартом модель процесса оценивания качества ПС приведена на рис. 45.
Основные стадии процесса оценивания качества ПС:
142
©¾ÊÌÉÊÔÁ
ÇÃÉÌ¿¾ÆÁ¾
¨ÉÇϾÊÊ
ÇϾÆÃÁ
¨Ç½½¾É¿Ã¹
ÇϾÆÃÁ
¨ÉÇϾÊÊ
ÇϾÆÃÁ
¨ÉǼɹÅÅÆÔÂÈÉǽÌÃË
›ÆÌËɾÆÆÁ¾
žËÉÁÃÁ
¶Í;ÃË
ÇËÈÉǼɹÅ
ÅÆǼÇÈÉǽÌÃ˹
›Æ¾ÑÆÁ¾
žËÉÁÃÁ
£¹Ð¾ÊË»Ç
»ÁÊÈÇÄÕÀÇ
»¹ÆÁÁ
Рис. 44. Взаимосвязь стандартов ISO/IEC 9126 и ISO/IEC 14598
¬Ê˹ÆǻľÆÆÔ¾
ÁÄÁ
Èɾ½ÈÇĹ¼¹¾ÅÔ¾
ËɾºÇ»¹ÆÁØ
§Èɾ½¾Ä¾ÆÁ¾
ËɾºÇ»¹ÆÁÂ
ùоÊË»¹
*40*&$ ½É̼¹Ø˾ÎÆÁоÊùØ
ÁÆÍÇÉŹÏÁØ
™½ÅÁÆÁÊËɹËÁ»ÆÔ¾
ËɾºÇ»¹ÆÁØ
§Èɾ½¾Ä¾ÆÁ¾
ËɾºÇ»¹ÆÁÂ
ªÈ¾ÏÁÍÁоÊÃÁ¾
ËɾºÇ»¹ÆÁØ
ùоÊË»¹
›ÔºÇÉžËÉÁÃ
©¹ÀɹºÇËù
ÈÉǼɹÅÅÆǼÇ
Ǻ¾ÊȾоÆÁØ
¨ÉÇž¿ÌËÇÐƹØ
ÈÉǽÌÃÏÁØ
ÈÉǽÌÃÏÁØ
§Èɾ½¾Ä¾ÆÁ¾
ÌÉÇ»ÆØ
ɹƿÁÉÇ»¹ÆÁØ
§Èɾ½¾Ä¾ÆÁ¾
ÃÉÁ˾ÉÁØ
ÇϾÆÃÁ
¨Ç½¼ÇËǻù
¡ÀžɾÆÆÔ¾
ÀƹоÆÁØ
¡ÀžɾÆÁØ
©¹Æ¿ÁÉÇ»¹ÆÁ¾
§Ï¾ÆÁ»¹ÆÁ¾
¬Ê˹ÆǻľÆÆÔÂ
ÌÉÇ»¾ÆÕ
©¾ÀÌÄÕ˹Ë
ÈÉÁ¾ÅľÅÔÂ
§Ï¾Æù
ƾÈÉÁ¾ÅľÅÔÂ
Рис. 45. Модель процесса оценивания качества ПС
– установление требований к качеству (определение назначения оценивания, идентификация типов ПС, разработка модели
качества);
– подготовка к оцениванию (выбор метрик качества);
– определение уровней ранжирования (определение границ
установленного уровня качества для каждого отдельного требования, определение критерия оценивания);
143
¡ÆÍÇÉŹÏÁÇÆÆÔ¾ËɾºÇ»¹ÆÁØ
¡ÆÍÇÉŹÏÁÇÆÆÔÂ
ÈÉǽÌÃË
¡Æ˾ÉÈɾ˹ÏÁØ
¡Æ½ÁùËÇÉ
™Æ¹ÄÁËÁоÊùØ
Åǽ¾ÄÕ
¡ÀžÉÁŹØ
ÃÇÆϾÈÏÁØ
¨ÉÇÁÀ»Ç½Æ¹Øžɹ
¨ÉÇÁÀ»Ç½Æ¹Øžɹ
­ÌÆÃÏÁØ
ÁÀžɾÆÁØ
ªÌÒÆÇÊËÕ
š¹ÀÇ»¹Øžɹ
š¹ÀÇ»¹Øžɹ
¥¾ËǽÁÀžɾÆÁØ
¥¾ËǽÁÀžɾÆÁØ
™ËÉÁºÌË
™ËÉÁºÌË
Рис. 46. Информационная модель измерений согласно ISO/IEC 15939
– оценивание (измерение, сопоставление измерений с критериями и обобщение результатов).
Стандарт ISO/IEC 15939
Стандарт ISO/IEC 15939 [93] вводит информационную модель
измерений, представленную на рис. 46.
Согласно стандарту, информационная модель распределяется
по трем секциям: сбор данных, подготовка данных и анализ данных [104].
На рис. 47 показаны соответствия между этой информационной моделью (левая часть рисунка), измерением и оцениванием
качества ПС по стандартам ISO серий 9126 и 14598.
Стандарт ISO/IEC 25000
Одна из целей разработки серии стандартов 25000 [10], позиционируемых как замена ISO/IEC 9126 и ISO/IEC 14598, состоит в согласовании терминов со стандартом ISO/IEC 15939 [45],
термины которого в основном являются определениями ISO по
метрологии.
144
145
™ËÉÁºÌË
¥¾ËǽÁÀžɾÆÁØ
š¹ÀÇ»¹Øžɹ
¥¾ËÉÁÃÁ»Åǽ¾ÄØλÆÌËɾÆƾ¼Ç »Æ¾Ñƾ¼ÇùоÊË»¹Á
ùоÊË»¹»ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
*40 *&$ ®¹É¹Ã˾ÉÁÊËÁÃÁ ÈǽιɹÃ˾ÉÁÊËÁÃÁÁžËÉÁÃÁ»Åǽ¾ÄØÎ
»ÆÌËɾÆƾ¼Ç »Æ¾Ñƾ¼ÇùоÊË»¹ÁùоÊË»¹»ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
*40 *&$ ¥Ç½¾ÄÁ»ÆÌËɾÆƾ¼Ç »Æ¾Ñƾ¼ÇùоÊË»¹ÁùоÊË»¹
»ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
*40 *&$ §Ï¾ÆùùоÊË»¹¨ª
*40 *&$ *40 *&$
*40 *&$
*40 *&$
*40 *&$
*40 *&$
Рис. 47. Соотношение между информационной моделью ISO/IEC 15939 и стандартами
ISO/IEC 9126, ISO/IEC 14598
ªºÇɽ¹ÆÆÔÎ
­ÌÆÃÏÁØÁÀžɾÆÁØ
¨ÉÇÁÀ»Ç½Æ¹Øžɹ
¨Ç½¼ÇËǻù½¹ÆÆÔÎ
™Æ¹ÄÁËÁоÊÃ¹Ø Åǽ¾ÄÕ
¡Æ½ÁùËÇÉ
¡Æ˾ÉÈɾ˹ÏÁØ
™Æ¹ÄÁÀ½¹ÆÆÔÎ
¡ÆÍÇÉŹÏÁÇÆÆÔÂÈÉǽÌÃË
Группа измерения качества (ISO 2502n) содержит пять документов [27–30]:
– ISO 25020. Measurement Reference Model and Guide (Ссылочная модель и руководство по измерениям);
– ISO 25021. Quality Measure Elements (Элементы мер качества);
– ISO 25022. Measurement of Internal Quality (Измерение внутреннего качества);
– ISO 25023. Measurement of External Quality (Измерение
внешнего качества);
– ISO 25024. Measurement of Quality in Use (Измерение качества в использовании).
Последние три документа регламентируют измерения внутреннего, внешнего и качества в использовании, модели качества
для которых содержатся в серии ISO/IEC 2501n (в документах
группы модели качества).
£¹Ð¾ÊË»ÇÈÉǼɹÅÅÆǼÇ
ÈÉǽÌÃ˹
ÊÇÊËÇÁËÁÀ
®¹É¹Ã˾ÉÁÊËÁùùоÊË»¹
ÁÀžÉØ×Ë
¥¾ÉÔùоÊË»¹
ÁÀžÉØ×Ë
ÊÇÊËÇÁËÁÀ
¼¾Æ¾ÉÁÉ̾Ë
­ÌÆÃÏÁØÁÀžɾÆÁØ
¨Ç½Î¹É¹Ã˾ÉÁÊËÁùùоÊË»¹
Ǻɹº¹ËÔ»¹×ËÊØ
¶Ä¾Å¾ÆËÔÁÀžɾÆÁØ
ùоÊË»¹
Рис. 48. Концепция элементов мер качества
£ÇÆϾÈÏÁØ
ÁÀžɾÆÁØ
£ÇÆϾÈÏÁØ
ÁÀžɾÆÁØ
±Ã¹Ä¹ÁÀžɾÆÁÂ
¦ÇÅÁƹÄÕƹØ
¡Æ˾ɻ¹ÄÕƹØ
›ÆÌËɾÆƾ¾
ùоÊË»Ç
¨ÇÉؽÃÇ»¹Ø
™ºÊÇÄ×ËƹØ
›Æ¾Ñƾ¾
ùоÊË»Ç
š¹ÀÇ»¹Ø
¥¾Ëǽ
ÁÀžɾÆÁØ
ªÌºÓ¾ÃËÁ»ÆÔÂ
¨ÉÇÁÀ»Ç½Æ¹Ø
§ËÆÇÊÁ˾ÄÕƹØ
£¹Ð¾Ê˻ǻ
ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
§ºÓ¾ÃËÁ»ÆÔÂ
¡ÀžÉÁ˾ÄÕÆÔÂÈÉÁÅÁËÁ»
Рис. 49. Концепция измерительных примитивов
146
«É¾ºÇ»¹ÆÁØÃùоÊË»ÌÇËоËǺ
ÇϾÆþùоÊË»¹
§Ï¾Æù
¹Æ¹ÄÁÀ
ɹƿÁÉÇ»¹ÆÁ¾
¥¾ÉÔùоÊË»¹
­ÌÆÃÏÁØ
£ÇÆϾÈÏÁØÈÉÁÅÁËÁ»Ç»ÁÀžɾÆÁÂ
¡ÀžÉÁ˾ÄÕÆÔ¾ÈÉÁÅÁËÁ»Ô
¥¾ËǽÁÀžɾÆÁØ
™ËÉÁºÌËÔ¨ª
Рис. 50. Место измерительных примитивов в модели измерений
Стандарт вводит понятия «элементов измерения качества»,
которые являются входами для процессов «измерений качества
ПС». На рис. 48 показаны отношения между «элементами измерения качества» и «измерениями качества ПС», между «измерениями качества ПС» и характеристиками и подхарактеристиками.
В стандарте вводится понятие «измерительные примитивы
(меры)» (рис. 49), которые бывают базовыми или производными.
Группа ISO/IEC 25020 вводит модель измерений, которая может
быть использована как в процессе определения требований к качеству ПС, так и в процессе оценивания качества ПС.
Стандарт содержит определения основных классов измерительных примитивов (таких как количество функций, размер
ПС, время выполнения и т. п.). На рис. 50 приведено место концепции измерительных примитивов в модели измерений, на
рис. 51 – примеры этой концепции.
Согласно стандарту, модель качества отражает отношения
между концептуальными элементами качества (характеристиками и подхарактеристиками), для оценивания этих концептуальных элементов служат соответствующие меры (рис. 52).
В стандарте описана процедура оценивания качества, модель
которой приведена на рис. 53.
147
£ÇÆϾÈÏÁØ
ÁÀžɾÆÁØ
š¹ÀÇ»¹Ø
¨ÉÇÁÀ»Ç½Æ¹Ø
±Ã¹Ä¹
ÁÀžɾÆÁÂ
¦¹ÁžÆÇ»¹ÆÁÂ
¨ÇÉؽÃÇ»¹Ø
£ÇÄÁоÊË»Ç
ÍÌÆÃÏÁÂ
­ÁÀÁоÊùØ
½ÇÊËÌÈÆÇÊËÕ
›É¾ÅØÀ¹½¹ÐÁ
›É¾ÅØ
Ç¿Á½¹ÆÁØ
£ÇÄÁоÊË»Ç
À¹½¹Ð
¶Í;ÃËÁ»
ÆÇÊËÕÀ¹½¹ÐÁ
¡Æ˾ɻ¹ÄÕƹØ
™ºÊÇÄ×ËƹØ
§ËÆÇÊÁ˾ÄÕƹØ
£ÇÆϾÈÏÁØ
ÁÀžɾÆÁØ
›ÆÌËɾÆƾ¾
ùоÊË»Ç
›Æ¾Ñƾ¾
ùоÊË»Ç
£¹Ð¾Ê˻ǻ
ÁÊÈÇÄÕÀÇ»¹ÆÁÁ
¥¾Ëǽ
ÁÀžɾÆÁØ
ªÌºÓ¾ÃËÁ»ÆÔÂ
§ºÓ¾ÃËÁ»ÆÔÂ
£Ä¹ÊÊÔÈÉÁÅÁËÁ»Ç»
¡ÀžÉÁ˾ÄÕÆÔ¾ÈÉÁÅÁËÁ»Ô
¥¾ÉÔùоÊË»¹
Рис. 51. Пример измерительных примитивов и мер качества
На рис. 54 приведена схема соответствия между моделями
оценивания качества, вводимыми стандартами ISO/IEC 15939 и
ISO/IEC 25000.
148
Èɾ½Ê˹»ÄؾË
®¹É¹Ã˾ÉÁÊËÁùùоÊË»¹
¥¾É¹Ã¹Ð¾ÊË»¹
Êǽ¾É¿ÁË
¼¾Æ¾ÉÁÉ̾Ë
Èɾ½Ê˹»ÄؾË
¨Ç½Î¹É¹Ã˾ÉÁÊËÁùùоÊË»¹
¥¾É¹Ã¹Ð¾ÊË»¹
¼¾Æ¾ÉÁÉ̾Ë
Êǽ¾É¿ÁË
Èɾ½Ê˹»ÄؾË
™ËÉÁºÌË
¡ÀžÉÁ˾ÄÕÆÔÂÈÉÁÅÁËÁ»
Рис. 52. Отношения между элементами модели качества
и элементами модели измерений
§Èɾ½¾Ä¾ÆÁ¾Æ¹ÀƹоÆÁØÇϾÆÃÁ
¡½¾ÆËÁÍÁùÏÁØËÁÈÇ»ÈÉǽÌÃËÇ»
Èǽľ¿¹ÒÁÎÇϾÆþ
¨Ç½¼ÇËǻùÇϾÆÃÁ
©¹ÀɹºÇËùÊËɹ˾¼ÁÁÇϾÆÃÁ
§Èɾ½¾Ä¾ÆÁ¾ËɾºÇ»¹ÆÁÂÃùоÊË»Ì
¨ª
­ÁÃʹÏÁØËɾºÇ»¹ÆÁÂ
ÃÇϾÆþ
§Èɾ½¾Ä¾ÆÁ¾ÇºÓ¾Å¹ÇϾÆÃÁ
§Èɾ½¾Ä¾ÆÁ¾ËɾºÇ»¹ÆÁÂÃÊËÉǼÇÊËÁ
Áƹ½¾¿ÆÇÊËÁÇϾÆÃÁ
ªÈ¾ÏÁÍÁùÏÁØÇϾÆÃÁ
›ÔºÇÉžÉ
§Èɾ½¾Ä¾ÆÁ¾ÌÉǻƾÂɹƿÁÉÇ»¹ÆÁØ
žÉ
¨ÉǾÃËÁÉÇ»¹ÆÁ¾ÇϾÆÃÁ
›ÔÈÇÄƾÆÁ¾ÇϾÆÃÁ
§Èɾ½¾Ä¾ÆÁ¾ÃÉÁ˾ÉÁ¾»ÇϾÆÃÁ
ÇÃÌžÆËÁÉÇ»¹ÆÁ¾Å¾ËǽǻÇϾÆÃÁ
¨Ä¹ÆÁÉÇ»¹ÆÁ¾½¾ÂÊË»ÁÂÈÇÇϾÆþ
¨ÉÇ»¾½¾ÆÁ¾ÁÀžɾÆÁÂ
©¹Æ¿ÁÉÇ»¹ÆÁ¾É¾ÀÌÄÕ˹ËÇ»ÁÀžɾÆÁÂ
§Ï¾ÆùɾÀÌÄÕ˹ËÇ»
Рис. 53. Модель процедуры оценивания
Как видно из рис. 54, модель измерений ISO/IEC 25020
представляет собой частный случай информационной модели
ISO/IEC 15939.
149
¡ÆÍÇÉŹÏÁÇÆÆÔÂÈÉǽÌÃË
¡Æ˾ÉÈɾ˹ÏÁØ
¡Æ½ÁùËÇÉ
™Æ¹ÄÁËÁоÊùØ
Åǽ¾ÄÕ
¥¾É¹Ã¹Ð¾ÊË»¹
¨ÉÇÁÀ»Ç½Æ¹Øžɹ
­ÌÆÃÏÁØÁÀžɾÆÁØ
­ÌÆÃÏÁØÁÀžɾÆÁØ
¡ÀžÉÁ˾ÄÕÆÔÂÈÉÁÅÁËÁ»
š¹ÀÇ»¹Øžɹ
¥¾ËǽÁÀžɾÆÁØ
¥¾ËǽÁÀžɾÆÁØ
™ËÉÁºÌË
™ËÉÁºÌË
*40 *&$
*40 *&$
Рис. 54. Отношения модели измерений ISO/IEC 25020
и информационной модели ISO/IEC 15939
<ƾË>
§Èɾ½¾Ä¾ÆÁ¾Ï¾Ä¾ÂÇϾÆÁ»¹ÆÁØ
©¹ÀɹºÇËùÅǽ¾ÄÁùоÊË»¹
œ¾Æ¾É¹ÏÁØÅǽ¾ÄÁÁÀžɾÆÁÂ
¨ÇÁÊú¹ÀÇ»ÔΞËÉÁÃ
§Èɾ½¾Ä¾ÆÁ¾ÈÉÇÁÀ»Ç½ÆÔΞËÉÁÃ
¯¾ÄÁÇϾÆÁ»¹ÆÁؽÇÊËÁ¼ÆÌËÔ
™Æ¹ÄÁÀùоÊË»¹¨ª
§Èɾ½¾Ä¾ÆÁ¾Í¹ÃËÁоÊÃÁÎÀƹоÆÁžËÉÁÃ
§Èɾ½¾Ä¾ÆÁ¾ÈÇÉǼǻÔÎÀƹоÆÁžËÉÁÃ
­ÇÉŹÄÁÀ¹ÏÁØžËÉÁÃ
¥Ç½¾ÄÁÉÇ»¹ÆÁ¾¨ª
Рис. 55. Обобщенная модель оценивания качества
150
3.2.2. Процесс оценивания качества программных средств
Процесс оценивания качества основывается на модели качества, описывающей высокоуровневые характеристики качества,
подхарактеристики, метрики и их взаимосвязи на концептуальном уровне. На основе концептуальной модели качества генерируется модель измерений ПС, в которой каждому элементу
модели качества ставится в соответствие определенная производная метрика. Затем задаются пороговые значения метрик для
определения на модели измерений, представляющей собой категорию метрических пространств, дефектных или эталонных
подпространств. На основе измерений фактических значений
метрик программные сущности могут быть отнесены к дефектным или эталонным и определен интегральный уровень качества
ПС. На рис. 55 процесс, реализующий алгоритм оценивания качества ПС, представлен в нотации диаграммы действий UML.
Рассмотрим этапы оценивания качества ПС в соответствии с
предлагаемым алгоритмом подробнее.
Определение целей оценивания
Стоящая перед экспертами цель оценивания влияет на разрабатываемую модель качества и, следовательно, на весь процесс
оценивания. Положим в качестве целей оценивания определение уровня качества ОО ПС по стандарту ISO/IEC 25000.
Разработка модели качества
Для упрощения изложения примем, что главной оцениваемой
характеристикой качества является «Удобство сопровождения».
R
›ÆÌËɾÆƾ¾Á »Æ¾Ñƾ¾
ùоÊË»Ç

®¹É¹Ã˾ÉÁÊËÁÃÁ
...

¨Ç½Î¹É¹Ã˾
ÉÁÊËÁÃÁ
R
¬½ÇºÊË»Ç
ÈÉÇ»¾ÉÃÁ
R
›ÔÊÇÃǾ
ÊϾÈľÆÁ¾
R
¬½ÇºÊË»Ç
...
ÊÇÈÉǻǿ½¾ÆÁØ 
ªË¹ºÁÄÕ
ÆÇÊËÕ


R

¬½ÇºÊ˻ǻƾʾÆÁØ R
ÁÀžƾÆÁÂ

 
¦ÁÀùØ
Ê»ØÀÆÇÊËÕ
R R


™Æ¹ÄÁÀÁ R
É̾ÅÇÊËÕ 

R
§ËÊÌËÊË»Á¾
§ËÊÌËÊË»Á¾
ÃĹÊÊÇ»½¹ÆÆÔÎ ÃĹÊÊÇ»ÅÇÆÊËÉÇ»
¨ÉÁÆÏÁÈÔ
ÈÉǾÃËÁÉÇ»¹ÆÁØ
Рис. 56. Пример модели качества
151
Согласно стандарту ISO/IEC 25000, эта характеристика зависит
от подхарактеристик «Удобство проверки», «Стабильность»,
«Удобство внесения изменений», «Анализируемость» и «Соответствие стандартам сопровождения». Декомпозируем подхарактеристики качества на ряд принципов проектирования применительно к объектно-ориентированному стилю. Это принципы «Высокое сцепление», отражающий необходимость усиления
использования методами внутренней структуры того же класса;
«Низкая связность», состоящий в уменьшении межклассовых
зависимостей; «Отсутствие классов-данных», т. е. классов, использующихся только в качестве структур данных для методов
других классов, и «Отсутствие классов-монстров», проявляющееся в существовании большого и сложного класса, который мало
зависит от остальных классов и предоставляет им мало функциональности. Построим модель качества (рис. 56).
Генерация модели измерений
Модель измерений ПС генерируется путем применения функтора из модели качества. Функтор QM:Q→MS является контравариантным одноместным функтором, отображающим объекты
категории качества (характеристики, подхарактеристики, принципы проектирования) на метрические пространства категории
измерений QM(Ob(Q))=Ob(MS), а морфизмы категории качества – на морфизмы категории измерений, являющиеся операторами комплексирования над метрическими пространствами
QM(Mor(Q))=Mor(MS).
Результат применения функтора к рассматриваемой модели
качества приведен на рис. 57.
. E
›ÆÌËɾÆƾ¾Á »Æ¾Ñƾ¾
ùоÊË»Ç
" D
D
"
.E
¬½ÇºÊË»Ç
ÈÉÇ»¾ÉÃÁ
.E
D D
"
"
.E
›ÔÊÇÃǾ
ÊϾÈľÆÁ¾
D
" .E
¬½ÇºÊË»Ç
ÊÇÈÉǻǿ½¾ÆÁØ D
" ªË¹ºÁÄÕ
ÆÇÊËÕ
D
D
D
"
¦ÁÀùØ
Ê»ØÀÆÇÊËÕ
. .
E
E
D
"
D
"
D
"
E
§ËÊÌËÊË»Á¾
§ËÊÌËÊË»Á¾
.
ÃĹÊÊÇ»½¹ÆÆÔÎ ÃĹÊÊÇ»ÅÇÆÊËÉÇ» Рис. 57. Пример модели измерений
152
E
™Æ¹ÄÁÀÁ .
É̾ÅÇÊËÕ
ÁÀžƾÆÁÂ
"
"
D
"
E
¬½ÇºÊ˻ǻƾʾÆÁØ .
Подбор метрик
Назначение процесса подбора метрик состоит в формировании измерительного базиса из производных и базовых метрик,
необходимого и достаточного для обеспечения полноты измерений всех элементов модели качества. Процесс подбора метрик
основывается на существующих стандартах, мнениях экспертов,
достигнутых положительных примерах управления качеством
ПС. При подборе метрик необходимо учитывать следующие требования:
– существенность составляющих метрики для итогового оценивания показателя (в смысле ясности потенциальной выгоды
использования каждой метрики);
– состоятельность метрики при наличии в аттестующей модели качества конфликтующих свойств (т. е. существование такого
набора значений показателей конфликтующих характеристик,
при котором комплексный показатель достигает своего максимума);
– возможность автоматизации определения значения метрики;
– малая дисперсия.
Выберем следующие метрики для оценивания ПС:
1) метрики связности: количество классов, которые использует данный класс (NR); количество классов, которые используют
данный класс, при условии, что и данный класс использует эти
классы (NBR); количество использований абстрактного предка
данного класса, разделенное на количество использований данного класса непосредственно (NABR); количество классов, которые используют данный класс (NAR); количество классов, которые используют абстрактного предка данного класса (NRA);
2) метрики сцепления: количество пар методов, которые не
используют общие поля класса, минус количество пар методов,
которые используют общие поля класса (LCOM), количество пар
методов, которые не используют общие поля класса (PP), количество пар методов, которые используют общие поля класса (QP),
количество методов класса, которые не используют поля класса
(NMWA);
3) метрики классов-данных: количество «функциональных»
общедоступных методов (WOCF), количество общедоступных
методов (WOCM), количество «функциональных» общедоступных методов, разделенное на количество общедоступных методов
153
154
C
.
11
"
D .
E
E
.
D
"
C
.
E
D
"
D
D D "
D
" C
.
/"3
D
"
C
.
/3"
D
"
C
.
80$'
D "
E
.
/"#3
D D
" "
/#3
E
.
D E
C
.
D
"
C
.
E
D
D C
. /0"
E
C
D "
.
D
C
.
"5'%
"
D "
.$
8.$
"
E
.
C
. /.
D "
5$$
C
.
21
"
D E
.
D "
E
§ËÊÌËÊË»Á¾
.
ÃĹÊÊÇ»ÅÇÆÊËÉÇ» D "
. " .
/01
/01"
D " 80$
80$.
D "
.
D "
D "
§ËÊÌËÊË»Á¾
ÃĹÊÊÇ»½¹ÆÆÔÎ
D "
E
.
"
E
¦ÁÀùØÊ»ØÀÆÇÊËÕ .
"
™Æ¹ÄÁÀÁÉ̾ÅÇÊËÕ
D
" Рис. 58. Результирующая модель измерений ПС
C
"
.
/3
D "
D
D "
"
D E
¬½ÇºÊ˻ǻƾʾÆÁØ . ÁÀžƾÆÁÂ
D
" E
.
"
D
E
.
¬½ÇºÊË»Ç
ÊÇÈÉǻǿ½¾ÆÁØ
¬½ÇºÊË»Ç . ªË¹ºÁÄÕÆÇÊËÕ
ÈÉÇ»¾ÉÃÁ
"
/.8"
D "
C
.
21
-$0.
"
D ›ÔÊÇÃǾ
ÊϾÈľÆÁ¾
E
.
D
"
›ÆÌËɾÆƾ¾Á
»Æ¾Ñƾ¾
ùоÊË»Ç
(WOC), количество общедоступных полей (NOPA), количество
геттер- или сеттер-методов (NOA), количество общедоступных
полей плюс количество геттер- или сеттер-методов (NOP), цикломатическая сложность метода класса (MC), взвешенное количество методов – сумма цикломатических сложностей всех методов
класса (WMC);
4) метрики классов-монстров: взвешенное количество методов – сумма цикломатических сложностей всех методов класса
(WMC), количество полей независимых классов, к которым обращаются методы данного класса (ATFD), количество пар методов, которые используют общие поля класса (QP), количество методов класса (NM), крепость сцепления класса – относительное
число пар методов класса, которые получают доступ, минимум,
к одному и тому же полю этого класса (TCC).
На рис. 58 представлена результирующая модель измерений
ПС.
Моделирование программных средств
Следует подчеркнуть, что при моделировании ПС не ставится
задачи формального представления всех ее свойств. Для целей
оценивания необходимо и достаточно формально описать только
те свойства ПС, от которых зависит расчет базовых метрик.
Сущности программы представляются вершинами, метки
которых представляют собой пары из имени и типа сущности.
Множество VG={Cl,Va,Me,Ge,Lo} всех возможных типов вершин
служит для представления, соответственно, класса, открытого
поля, метода, открытого геттер- или сеттер-метода, оператора
цикла. Отношения между программными сущностями представляются с помощью ребер. Множество EG={in,us,me,ty,ac,co} всех
возможных типов ребер представлено в табл. 17.
Таблица 17
Ребра графа
Тип ребра
Описание
in:Cl→Cl
Использование абстрактного предка класса
us:Cl→Cl
Использование класса
me:Va→Cl Принадлежность поля классу
me:Me→Cl Принадлежность метода классу
me:Ge→Cl
Принадлежность открытого геттер- или сеттер-метода
классу
155
Окончание табл. 17
Тип ребра
ty:Va→Cl
Описание
Классовый тип поля
ac:Me→Va Доступ к полю из метода
ac:Ge→Va
Доступ к полю из открытого геттер- или сеттер-метода
co:Lo→Me Принадлежность оператора цикла методу
co:Lo→Lo
Вложенность операторов циклов
С помощью такой нотации ПС представляется как типизированный помеченный граф.
Формализация метрик
На этом этапе на основе графовой модели ПС определяются
формулы для расчета базовых метрик, затем вводятся формулы
для расчета производных метрик. В табл. 18 приведены формулы
для расчета метрик уровня класса. Везде в формулах v обозначает идентификатор вершины, соответствующей оцениваемому
классу, µ – метрику уровня классов.
Таблица 18
Формулы расчета метрик уровня класса
Обозначение
Формула
NR
NBR
NABR
µ4b5
µ2d4 =
= ovec(v, C,us)
{s(e) : e Î OVG (v) Ù vt(t(e)) = Cl Ù et(e) = us} ∩
{t(e) : e Î IVG (v) Ù vt(s(e)) = Cl Ù et(e) = us}
ãäå OVG (v) = {s(e) : e Î { EG : t(e) = v}},
IVG (v) = {t(e) : e Î { EG : t(e) = v}}
µ3d4 =
ivec(v, Cl, in)
ivec(v, Cl,us)
NAR
µ5b5 = ivec(v, Cl,us)
NRA
µ6b5 = ivec(v, Cl, in)
LCOM
µ1d4 = µ1d5 - µ2d5
PP
1 ,m2 Î{ s(e)ÎIVG (v): {m }
µ1b5 = å m
2
vt(s(e))= Me}Ù
OVG (m1 )ÇOVG (m2 ) =1
156
,
Окончание табл. 18
Обозначение
QP
Формула
µ2b5 = å f Î{s(e)ÎIVG (v):
vt(s(e))=Va}
ivec(f, Me, ac)!
2 !(ivec(f, Me, ac) - 2)!
NMWA
µ3b5 = {m Î {s(e) Î IVG (v) : vt(s(e)) = Me} Ù OVG (m) = 1}
WOCF
µ7b5 = ivc(v, Me) - ivc(v, Ge)
WOCM
µ8b5 = ivc(v, Me)
WOC
µd4 4 =
µ7d5
µd85
= 1-
ivc(v, Ge)
ivc(v, Me)
NOPA
µ9b5 = ivc(v, Va)
NOA
b5
µ10
= ivc(v, Ge)
NOP
b5
µ5b4 = µ9b5 + µ10
= ivc(v, Va) + ivc(v, Ge)
MC
WMC
µ5d4 = max(ipath(me, Lo, co))
µ6d4 = å mÎ{s(e)ÎIVG (v): µ5d4 (m) =
vt(s(e))= Me}
IVG (v): max(ipath(me, Lo, co))
å mvtÎ(s{(se())e)=ÎM
}
ATFD
b5
µ12
= å mÎ{s(e)ÎIVG (v): {OVG (m)} / { IVG (v)}
vt(s(e))= Me}
NM
b5
µ13
= ivc(v, Me)
TCC
µ7d4 =
µ2b5
b5
µ13
На основе формул метрик уровня классов определяются формулы метрик уровня системы. Общий вид этих формул следующий:
n
å µdij (vl )
mjdi = l=1
n
,
157
где mjdi – метрика уровня системы, заданная на пространстве
Mjdi ; vl – класс; n – количество классов.
Преобразованные таким образом метрики уровня классов образуют метрические пространства уровня системы, на основе которых формируются новые производные пространства для расчета остальных высокоуровневых метрик ПС (табл. 19).
Таблица 19
Формулы расчета метрик уровня системы
Обозначение
Формула
Высокое сцепление
Низкая связность
Отсутствие классов-данных
Отсутствие классов-монстров
m1d3 =
m2d3 =
m4d4 + m5d4 + 2m6d4
4
m4d3 =
d5
m6d4 + 3m12
+ m7d4
5
m1d2 =
Стабильность
m2d2 =
Удобство внесения изменений
m4d2 =
m1d1 =
m1d3 + 5m2d3
6
4m1d3 + 3m2d3
7
m3d2 =
Анализируемость
Внутреннее и внешнее качество
m4d5 + m5d5 + 2m2d4 + 2m3d4
6
m3d3 =
Удобство проверки
Удобство сопровождения
3m1d4 + m3d5
4
m3d3 + 3m4d3
4
3m3d3 + 4m4d3
7
m1d2 + 2m2d2 + 5m3d2 + 3m4d2
11
m1d0 = m1d1
Определение пороговых и фактических значений метрик
В качестве ПС было выбрано специальное программное обеспечение военной телемедицины [105]. Система содержит порядка
170 000 строк кода, 487 классов на языке C++. Для определения
значений метрик было разработано ПС на языке C#. Значения
158
метрик определялись в соответствии с формулами для системы
целом. Пороговые значения представляют собой допустимый интервал, в пределах которого значение метрики интерпретируется как оптимальное.
Таблица 20
Расчетные значения метрик
Метрика
Допустимый интервал
Фактическое значение
[2,000, ¥ ]
3,250
m2d4 (NBR)
[0,333, ¥ ]
0,460
m3d4 (NABR)
[1,000, ¥ ]
1,211
m5b5 (NAR)
[1,000, ¥ ]
1,340
m6b5 (NRA)
[0,100, ¥ ]
0,254
m1d4 (LCOM)
[0,000, ¥ ]
0,118
m1b5 (PP)
[0,000, 1,000]
0,386
m2b5 (QP)
[0,333, ¥ ]
0,268
m3b5 (NMWA)
[0,000, 0,333]
0,156
m7b5 (WOCF)
[2,000, 10,000]
2,890
m8b5 (WOCM)
[3,000, 10,000]
3,780
m4d4 (WOC)
[0,500, 1,000]
0,765
m9b5 (NOPA)
[0,500, 1,000]
0,679
b5 (NOA)
m10
[2,000, 10,000]
3,892
m5b4 (NOP)
[2,500, 11,000]
4,571
d5 (MC)
m11
[0,100, 2,000]
0,256
m6d4 (WMC)
[0,100, 4,000]
0,348
b5 (ATFD)
m12
[0,100, 2,000]
0,328
m4b5
(NR)
159
Окончание табл. 20
Метрика
Допустимый интервал
Фактическое значение
[1,000, 10,000]
5,369
m7d4 (TCC)
[0,010, ¥ ]
0,022
m1d3 (высокое
сцепление)
[0,100, ¥ ]
0,128
m2d3 (низкая связность)
[1,000, 3,000]
1,322
m3d3 (отсутствие
классов-данных)
[1,000, 2,000]
1,442
m4d3 (отсутствие
классов-монстров)
[0,010, 1,000]
0,271
m1d2 (удобство
проверки)
[1,000, 2,000]
1,123
m2d2 (стабильность)
[0,500, 1,000]
0,640
m3d2 (удобство внесения
изменений)
[0,500, 1,000]
0,563
m4d2 (анализируемость)
[0,500, 1,000]
0,772
m1d1 (удобство
сопровождения)
[0,500, 1,000]
0,671
m1d0 (внутреннее
и внешнее качество)
[0,500, 1,000]
0,671
b5
m13
(NM)
Анализ результатов оценивания качества
программных средств
В результате расчета метрик каждому элементу модели качества сопоставляется определенное значение. По результатам
измерений можно сделать вывод о том, что в целом качество
анализируемого ПС является удовлетворительным. При этом
существуют метрики (метрика количества пар методов, которые
используют общие поля класса), чьи значения не принадлежат
допустимому интервалу. В этой ситуации может быть принято
решение о пересмотре как самого порогового интервала, так и
160
формулы расчета вышестоящей метрики. С другой стороны, на
основе нарушений метрик выявляются те программные сущности, которые необходимо переработать.
В общем случае существует возможность оценить качество
ПС в целом, а также любого отдельного компонента модели качества. Если качество ПС не было признано удовлетворительным, то выявляются отдельные характеристики качества, по
которым не были достигнуты приемлемые значения. Далее, воспользовавшись метриками уровня классов, выделяются те классы системы, метрики для которых не удовлетворяют пороговым
значениям. Эти классы являются кандидатами для проведения
рефакторинга, инспекций и других мероприятий по улучшению
качества кода. После проведения этих мероприятий должно происходить повторное оценивание качества с целью проверки принятых решений по преобразованию ПС.
При интерпретации результатов оценивания качества может
быть принято решение о необходимости внесения изменений в
процесс оценивания. Предприятия по изменению процесса оценивания могут быть следующих типов: изменение модели качества, корректировка производных и базовых метрик для оценивания качества, изменение функциональных зависимостей производных метрик качества.
161
Глава 4. Улучшение качества
программных средств
В случае, если результаты оценивания программного средства
не удовлетворяют принятым критериями качества, необходимо
определить набор мероприятий по улучшению качественного состояния программы. Для формального описания этих мероприятий целесообразно определить соответствующую модель. Так
как основой для модели программного средства послужили графы, то модель преобразований будет основана на преобразовании
графов.
4.1. Модель преобразований программных средств
4.1.1. Преобразования графов
Алгебраический метод использования графовых грамматик
был предложен в начале 70-х годов прошлого столетия в Берлинском университете Х. Еригом, М. Пфендером и Х. И. Шнайдером
[106]. Именно эти ученые впервые предприняли попытку обобщения грамматик Хомского со строковых на графовые структуры. В настоящее время их подход носит название двухвыводного (double-pushout), так как базируется на использовании промежуточного, исходного и целевого графов и выводов двух последних из первого. Позже появился подход, носящий название
одновыводного (sigle-pushout), в котором определялся один вывод между исходным и целевым графами в категории графов и
частичных графовых морфизмов [107]. Двухвыводной метод может быть рассмотрен как специальный случай одновыводного,
вместе с тем техника доказательств некоторых свойств выводов
для двухвыводного метода оказывается проще [123]. Сегодня обе
концепции широко используются для описания параллельных,
объектно-ориентированных, распределенных систем (например,
[109–113]).
Графовые модели позволяют описать свойства программных
артефактов и их отношений, а для описания их модификации используется теория перезаписи (переписывания) графов.
Идея систем перезаписи графов эволюционировала из теории
перезаписи термов. Первой в этой области считается работа [114]
1969 г., в которой Ж. Пфальц и А. Розенфельд в основном неформально обрисовали контуры теории перезаписи графов. Именно
в этой работе было введено понятие предусловий, которые долж162
ны иметь место для корректности перезаписи графа. В работе
[115], опять в недостаточно формализованной манере, было введено понятие негативных предусловий. Более формализованное
воплощение данные понятия нашли в работах [116, 117]. В работах [118] и [119] понятие предусловий было дополнено понятием
постусловий, которые необходимо соблюсти после применения
перезаписи графа.
В настоящее время существует большое количество различных подходов к формализации перезаписи графов и графовых
грамматик.
По способу организации правил перезаписи можно выделить
неупорядоченные, упорядоченные и событийно-управляемые
системы, последовательные и параллельные графовые грамматики.
С математической точки зрения можно классифицировать
подходы к формализации по принципу использования категорного (или алгебраического) [120] и теоретико-множественного
подходов. При использовании теоретико-множественного подхода множества используются для представления внутренней
структуры графа, а в алгебраическом подходе для этих целей используют категории и морфизмы. Более детальная классификация может быть сделана относительно применения одинарного
([121]) или двойного универсального квадрата при использовании алгебраического подхода. Подход с одинарным универсальным квадратом отличается большей элегантностью и позволяет
упростить некоторые доказательства.
Так как графы могут быть рассмотрены в качестве структур
данных, исследования графовых грамматик могут быть обобщены в рамках структурных грамматик (или структурных систем
перезаписи) [120]. В работе [121] вводится обобщенная категория графовых структур, использующаяся для доказательства
многих интересных свойств.
Одним из интересных примеров практического применения
теории перезаписи графов является язык программирования
PROGRESS (PROgramming with Graph Rewriting Systems) [123].
Язык использует императивные структуры для управления перезаписью графов.
Основные определения графовых преобразований
В работе [121] вводится категория графовых структур. Несложно убедиться в применимости всех введенных ранее определений
163
в рамках этой категории, так как, по сути, графы этой категории являются обобщением (L,A)-помеченных T-типизированных
графов. Категория графовых структур имеет одно важное свойство – закрытость с ограничением для конечных копределов. Отсюда следует гарантированное существование универсального
квадрата, что является необходимым в рамках удовлетворения
определению 84.
Мы адаптируем результаты [121] в рамках определения базиса для системы преобразования программных артефактов.
Другое используемое свойство было доказано в работе [20].
Оно состоит в утверждении о том, что все определения и свойства
обыкновенной графовой грамматики могут быть непосредственно транслированы в соответствующие определения и свойства
типизированной графовой грамматики.
Понятие продукций и выводов
Идея перезаписи графа состоит в том, что в левой части продукции описываются те вершины и ребра, которые должны
иметься в исходном графе, а в правой – как эта часть графа будет
выглядеть после применения продукции. Частичный морфизм
описывает отношения объектов левой части к правой, детализируя процесс применения правила. Объекты, не описываемые
морфизмом, удаляются; объекты, не изменяемые морфизмом,
формируют контекст продукции; объекты правой части продукции, не имеющие прообраза в левой части, создаются заново.
Продукция p состоит из левой части L, правой части R и частичного морфизма p. Для применения продукции p к графу G
подграф G, соответствующий L, заменяется на R, при этом p детализирует процесс трансформации, описывая, как именно R
включается в G. По виду и способу использования информации
по встраиванию правой части продукции в модифицируемый
граф также классифицируют системы перезаписи графов. Допускается пустота p, в этом случае все ребра, не принадлежащие L,
но входящие или выходящие из L, удаляются из модифицированного графа. Мы будем использовать подход, в рамках которого все ребра, соединенные с вершиной в L, будут соединены с соответствующей вершиной (при ее наличии) в R, что описывается
морфизмом p. При отсутствии соответствующего узла в R ребра
будут исключены из графа.
r
Определение 80. Продукция. Продукция p : (L ¾¾
® R) состоит из имени продукции p и инъективного частичного графового
164
морфизма r, называемого морфизмом продукции. Графы L и R
носят названия, соответственно, левой и правой частей продукr
ции. В случае однозначности контекста продукция p : (L ¾¾
® R)
r
будет обозначаться p, или L ¾¾
® R, или L→R.
Система перезаписи графа состоит из множества начальных
графов и множества продукций.
Определение 81. Система перезаписи графов. Система перезаписи графов Θ=({G0},P) содержит {G0} – множество начальных
графов и P – множество продукций.
Часто вместо системы перезаписи графов используется наименование грамматики. Во многом эти понятия совпадают, имеются и различия. В грамматике множество продукций синтезируют язык терминальных графов, а в качестве промежуточных
результатов используются нетерминальные графы. Система
перезаписи графов содержит множество правил, каждое из которых посвящено преобразованию одного экземпляра некоторого
класса графов в другой экземпляр того же класса, без каких-либо
различий между терминальными и нетерминальными графами.
Обычно только один граф выступает в качестве начального для
системы перезаписи графов.
Определение 82. Графовая грамматика. Графовая грамматика Γ представляет собой двойку Γ=<(p:r)p∈P,G0>, где (p:r)p∈P – семейство морфизмов продукций, упорядоченное по своим именам,
а G0 – начальный граф грамматики.
Лемма 14. Графовый коуравнитель. Пусть a,b:A→B – два частичных морфизма, таких, что для каждого x ∈ A, если и a, и b
определены на x, то a(x)=b(x). Тогда коуравнителем a и b в категории LGraph является двойка <C,c>, в которой C⊆B – наибольший подграф графа ([b( A) Ç a( A)] È [a( A) Ç b( A)]), dom(c)=C, причем c – тождественный морфизм на этой области определения.
Доказательство. Очевидно, что c°a=c°b. Свойство универсальности коуравнителя следует из того факта, что для всякого
другого морфизма d:B→D, для которого d°a=d°b, будет выполняться dom(d)⊆dom(c).
Эти определения характеризуют алгебраический подход к
описанию преобразований графов, в рамках которого перезапись
графа описывается с помощью графовых морфизмов и объединяющих конструкций. Использование алгебраического подхода отличает высокий уровень абстракции и лаконичность описания,
что упрощает многие доказательства.
165
Следующее определение описывает понятие прямого вывода.
Определение 83. Соответствие (совпадение). Соответствием
r
для продукции p : (L ¾¾
® R) называется тотальный морфизм
m:L→G.
Определение 84. Прямой вывод. Для продукции p и соответствия m для p в графе G, прямым выводом из G посредством p при
p
m
® H, является универсальный кваm, записывается как G ¾¾
драт для p и m в категории LGraph (рис. 59).
-
3
Q
N
N
Q
(
)
Рис. 59. Применение продукции как результат
универсального квадрата
Определение 85. Вывод. Выводом из G0 в Gn является послеr1
rn
® ¾¾®
Gn ), сокрадовательность прямых выводов ρ = (G0 ¾¾
m1
mn
щенно обозначаемая G0→*Gn.
Определение 86. Графовый язык. Графовым языком, порождаемым графовой грамматикой Γ, называют множество всех графов Gn, таких, что для каждого Gn существует вывод G0→*Gn с
помощью продукций грамматики Γ.
Перед применением продукции к графу для начала необходимо убедиться в том, что этот граф содержит все объекты, соответствующие левой части продукции. С этой целью введено понятие
соответствия – морфизма, тотальность которого следует из необходимости точного соответствия части исходного графа левой
части продукции. При этом допустимо, чтобы разные объекты
левой части продукции отображались на один объект исходного графа. Процесс трансформации исходного графа, в конечном
счете, заключается в замене объектов исходного графа, соответствующих левой части, на объекты правой части продукции.
Подграф L графа G называется вхождением L в G или совпадением для продукции p. Как показано на рис. 59, существование графа H, морфизма m*:R→H (который называется косовпадением m) и r*:G→H делает диаграмму коммутативной. Благо166
даря этому факту всякий прямой вывод определяется не только
соответствующей продукцией p, но также и соответствующим
совпадением m:L→G. Это определяет причину использования
r
® H. Необходимо иметь в виду, что благодаря
обозначения G ¾¾
m
использованию конструкции универсального квадрата H является минимальным графом, который может быть получен путем
применения продукции p к графу G (в смысле совпадения m).
Лемма 15. Универсальный квадрат в категории LGraph. Универсальный квадрат двух морфизмов b:A→B и c:A→C в категории LGraph всегда существует и может быть получен с помощью
следующих трех шагов (рис. 60).
EPN D
EPNC
"
$
#
P
$o
%
P
P
P
&
P
'
Рис. 60. Построение универсального квадрата
в категории Graph
Шаг 1. Построение универсального квадрата (C’,A→C’,C→C’)
тотальных морфизмов dom(c)→C и dom(c)→A в категории Graph.
Шаг 2. Построение универсального квадрата (D’,B→D’, C’→D)
тотальных морфизмов dom(b)→A→ C’ и dom(b)→B в категории
Graph.
Шаг 3. Построение коуравнителя (E,D→E) частичных морфизмов A→B→D и A→C→ C’→D в категории Graph.
Итог. (E,C→C’→D→E,B→D→F) – универсальный квадрат b и
c в категории LGraph.
Доказательство. Коммутативность сохраняется в процессе
построения. Допустим существование (F,C→F,B→F) с A→B→F=
=A→C→F. Покажем, что dom(b)→B→F=dom(b)→A→C’→F.
Используем тот факт, что универсальные квадраты в категории Graph являются универсальными квадратами в категории
LGraph [136] для построения универсального морфизма D→F.
Используя свойство универсального коуравнителя получим
уникальный морфизм E→F со свойствами B→D→E→F=B→F и
C→ C’→D→E→F=C→F.
167
На основе прямого вывода определяется понятие последовательности выводов.
С целью защиты от идентификационных конфликтов при поиске совпадения m в графе G, в рамках которых существует более
одного подходящего совпадения, вводится понятие конфликтносвободной продукции.
Определение 87. Конфликтно-свободная продукция. Пусть
m:L→G – соответствие для продукции p:L→R. m является
конфликтно-свободным соответствием для p, если из m(x)=m(y)
следует или x,y∈dom(p), или x,y∉dom(p).
Если m является инъективным совпадением, то соответствующая продукция всегда конфликтно-свободна.
Определение 88. dom-инъективное соответствие. m является
dom-инъективным соответствием для p, если из m(x)=m(y) следует или x=y, или x,y∈dom(p).
Определение 89. dom-полное соответствие. m является domполным соответствием для p, если для каждого ребра e∈EG с
sG(e)∈mV(VL–dom(p)V) или tG(e)∈mV(VL–dom(p)V) соблюдается
e∈mE(EL–dom(p)E).
Лемма 16. Свойства универсальных квадратов категории
LGraph. Пусть (H,p*:G→H,m*:R→H) – универсальный квадрат
при p:L→R и m:G→H в категории LGraph, тогда имеют место следующие свойства:
1) универсальные квадраты сохраняют сюръективность (инъективность), таким образом, сюръективность (инъективность) p
влечет сюръективность (инъективность) r*;
2) r* и m* совместно сюръективны;
3) конфликтная свобода m влечет тотальность m*.
Доказательство. См. [124].
Составные продукции
Составные продукции представляют собой упорядоченные
последовательности продукций [119]. Элементарные продукции объединяются в составные, рассматриваемые как атомарное действие, по аналогии с программной концепцией транзакции. В итоге или вся упорядоченная последовательность
элементарных продукций выполняется, или невозможность
выполнения одной из продукций влечет отмену выполнения
всех остальных продукций, входящих в последовательность
[125].
168
Для сравнения, в работе [125] транзакции графовых грамматик используются для представления рекурсивных, частичных
и недетерминистических программ перезаписи графов.
Встраивание может быть рассмотрено как семейство взаимнооднозначных соответствий между графами начального вывода и
встроенными графами.
Определение 90. Встраивание. Для двух выводов
p
m0
p
mn-1
p
k0
p
kn-1
1
n
1
n
ρ = (G0 ¾¾®
 ¾¾¾
® Gn ) и θ = (X0 ¾¾
® ¾¾¾
® Xn ) встраи-
вание ρ в Θ представляет собой семейство тотальных инъективei
® Xi )iÎ{1,…,n} , таких, что ei° mi=ki для
ных морфизмов e = (Gi ¾¾
всех i∈{1,…,n}.
e
На рис. 61 встраивание ρ в Θ обозначается ρ ¾¾
® θ, первый
инъективный морфизм e0:G0→X0 – встраивающим морфизмом e.
-
Q
N
N 
(
(
F
F
9
-O
3
QO
NOs
NOs
(Os
(O
FO
FOs
9
3O
9
9O
Рис. 61. Встраивание продукций
Для вывода ρ все возможные встраивания e в вывод Θ полностью определяются встраивающим морфизмом e0. Существование встраивания e:ρ→Θ в этой связи может быть описано в терминах вывода ρ и встраивающего морфизма e0. Впоследствии
может быть построена выведенная продукция, отражающая эффект вывода ρ, так что применимость этой выведенной продукции при соответствии e0 будет эквивалентна встраиванию e:ρ→Θ,
порожденному e0. Рассмотрим основной вариант прямого вывода, ведущий к понятию соответствующей продукции.
Определение 91. Непосредственно выведенная продукция.
p*
Непосредственно выведенная продукция < d >: G ¾¾® H пряp
® H) состоит из имени продукции <d> и
мого вывода d = (G ¾¾
m
частичного морфизма p*, представляющего собой копродукцию
<d>
® Y с использованием
прямого вывода. Прямой вывод X ¾¾¾
e
<d>:p* носит название непосредственно выведенного вывода.
169
Следующее свойство эквивалентности, соотносящее непосредственно выведенные выводы с встраиваниями начального
вывода, известно также как свойство вертикальной композиции
диаграмм вывода.
Лемма 17. Непосредственно выведенная продукция. Для непосредственно выведенной продукции <d>:p* прямого вывода
p
d = (G ¾¾
® H) (рис. 62) следующие утверждения являются экm
вивалентными:
1) существует
непосредственно
выведенный
вывод
<d>
d ¢ = (X ¾¾¾
® Y );
e
p
® Y) и
2) существует непосредственный вывод d ¢¢ = (X ¾¾
k
встраивание <e,e*>d′→d′′.
С точностью до изоморфизма, биективное соответствие между
1) и 2) описывается с помощью k=e°m.
N
N
Q
(
)
F
9
3
Q
Q
F
:
Рис. 62. Композиция прямых выводов
Доказательство. Непосредственно выведенный вывод 1)
представляется с помощью диаграмм универсальных квадратов
(1) и (2) на рис. 62. В силу свойства композиции универсальных
квадратов диаграмма (1+2) также является универсальным квадратом, представляющим прямой вывод в 2). Наоборот, можно
извлечь универсальные квадраты (1) и (2) из (1+2) посредством
квадрата (1) продукции p и соответствия m и квадрата (2) продукции p* и соответствия e. Уникальность квадратов с точностью
до изоморфизма гарантирует биективное соответствие между
1) и 2).
Определение 92. Последовательная композиция продукций.
Для двух продукций p1:L1→R1 и p2:L2→R2 при R1=L2 продукция
p
последовательной композиции p1; p2 : L1 ¾¾
® R2 состоит из име170
ни продукции p1;p2 и соответствующего частичного морфизма
p=p2°p1.
p1
p2
® H1 ¾¾®
H2 , в которых соответствие
Выводы вида G ¾¾
m1
m2
второго прямого вывода m2 является косоответствием первого, могут быть реализованы за один шаг с помощью составной продукции p1; p2 . Обратно, каждый прямой вывод вида
p1; p2
G ¾¾¾
® H2 может быть с помощью p1;p2 декомпозирован в
m1
p
m1
p
m1
1
2
® H1 ¾¾®
H2 , при условии, что косоответствие m1*
вывод G ¾¾
*
первого вывода является тотальным.
Лемма 18. Последовательная композиция. Для двух продукций p1 и p2 и их последовательной композиции p1;p2 следующие
утверждения являются эквивалентными:
p1; p2
® H2 , в которых m1 яв1) существует прямой вывод G ¾¾¾
m1
ляется конфликтно-свободным соответствием относительно p1;
p1
p2
® H1 ¾¾®
H2 , такой, что m1* яв2) существует вывод G ¾¾
m1
m1*
ляется косоответствием m1.
С точностью до изоморфизма, биективное соответствие между
1) и 2) описывается с помощью p=p2°p1.
Доказательство. Исходя из свойств универсальных квадратов
категории LGraph (лемма 16), косоответствие m* является тотальным тогда и только тогда, когда m – конфликтно-свободное соответствие относительно p1. Тогда утверждения 1) и 2) следуют из
свойств композиции и декомпозиции универсальных квадратов.
На рис. 63 поясняется определение 92. Требование конфликтной свободы необходимо для описания ситуаций, в которых
m1* – частичный. Если тотальный морфизм m1:L→G является
конфликтно-свободным, его косовпадение m1* будет тотальным.
Q Q
-
Q
Q
N
N
N
(
3
Q (
Q
Q 3
N
Q (
Рис. 63. Последовательная композиция
171
На практике требование R1=L2 в определении 92 является
слишком ограничивающим. В рамках расширения этого определения для работы с продукциями, которые не удовлетворяют
этому ограничению, эти продукции необходимо встроить в общий контекст до объединения в составную продукцию.
Определение 93. Составная продукция. Пусть mi:Li→Gi–1 являются соответствиями для продукций pi:Li→Ri для ∀i∈{1,…,n}.
Тогда p1* ;…; pn* : G0 ® Gn , определенная посредством композиции
pn* … p1* , носит название составной продукции.
Лемма 19. Существование составного вывода. Для последовательности
продукций p1,…,pn составной вывод вида
p1* ;…; pn*
X ¾¾¾¾
® Y с конфликтно-свободным соответствием e:G0→X
e
для pi при ∀i∈{1,…,n} существует тогда и только тогда, когда суp1
pn
® ¾¾¾®
Gn
ществует последовательность выводов G0 ¾¾¾
e1 m1
en mn
с соответствиями ei°mi:Li→Gi-1, такая, что e1=e и ei – косоответствие e относительно pi.
Определение
94.
Выведенная
продукция.
Пусть
p1
pn
ρ = (G0 ¾¾® ¾¾¾® Gn ) – вывод, состоящий из прямых выm0
mn-1
pi
di = (Gi-1 ¾¾¾
® Gi )
mi-1
водов
и < di >: pi* соответствующих
проp*
дукций. Выведенная продукция < ρ >: G0 ¾¾® Gk продукции ρ
состоит из имени, продукции <ρ>=<d1>;…;<dn> и соответствующего частичного морфизма p* = pn* … p1* .
Определение 95. Производный вывод. Прямой вывод
<ρ>
X ¾¾¾
® Y с использованием <ρ>:p* носит название производe
ного вывода.
Теорема
3.
О
выведенной
продукции.
Пусть
p1
pn
ρ = (G0 ¾¾®
 ¾¾¾
® Gn ) – вывод, <ρ>:p* – соответствующая
m0
mn-1
e0
выведенная продукция и G0 ¾¾
® X0 – dom-инъективное соответствие для <ρ>. Следующие высказывания являются эквивалентными:
<ρ>
® Xn ;
1) существует производный вывод X0 ¾¾¾
2) существует вывод
e
e0
p1
pn
θ = (X0 ¾¾® ¾¾¾
® Xn )
k0
kn-1
вместе с
встраиванием ρ ¾¾
® θ, где e0 – встраивающий морфизм e.
С точностью до изоморфизма, биективное соответствие между 1) и 2) описывается с помощью p* = pn* … p1* и ei°mi=ki, для
i∈{0,…,n–1}.
Доказательство. См. [108].
172
p
m0
p
mn-1
1
n
 ¾¾¾
® Gn ) –
Теорема 4. О встраивании. Пусть ρ = (G0 ¾¾®
e
0
вывод, G0 ¾¾
® X0 – встраивающий морфизм. Тогда существует
p
k0
p
kn-1
e
1
n
® ¾¾¾
® Xn ) и встраивание ρ ¾¾
вывод θ = (X0 ¾¾
® θ.
Выведенные продукции описывают суммарный эффект породившего их вывода. Существует возможность не представлять в
выводе элементы начальных и конечных графов, которые продукция не затронула. В работе [121] вводится понятие минимальной выведенной продукции для случаев 1≤n≤2, в работе [126] этот
подход обобщен для случаев n≥1.
Объединение и распределение продукций
Рассмотрим различные варианты последовательного применения продукций с возможной синхронизацией общедоступных
для продукций элементов графа. Синхронизация продукций относительно создаваемых (удаляемых) элементов графа обычно
описывается в терминах подпродукций.
Определение 96. Подпродукция. Пусть pi:Li→Ri – три продукции при i=0, 1, 2. Тогда p0 носит название подпродукции p1, если
существует встраивание e1 =< e1L , e1R >: p0 ® p1, т. е. двойка то-
тальных графовых морфизмов e1L : L0 ® L1 и e1R : R0 ® R1, таких,
что e1R  p0 = p1  e1L .
Определение 97. Синхронизированная продукция. Продукции p1 и p2 являются синхронизированными относительно p0
e1
e2
(обозначается p1 ¬¾¾ p0 ¾¾® p2 ), если p0 является одновременно подпродукцией p1 и p2 со встраиваниями соответственно
e1 и e2.
-
F3
F-
3
Q
Q
3
Рис. 64. Синхронизированные продукции
e1
e2
Если синхронизированные продукции p1 ¬¾¾ p0 ¾¾® p2
должны быть применены одновременно к одному графу, это можно смоделировать посредством выполнения объединенной продукции, построенной «склейкой» p1 и p2 с помощью p0. Формаль173
но эта «склейка» описывается с помощью универсального квадрата. Объединенные таким образом продукции обозначаются
p1 Å p0 p2 и представляют собой диаграмму (рис. 64), охватываю1
2
e
e
щую сами синхронизированные продукции p1 ¬¾
¾ p0 ¾¾® p2
и их встраивания в продукционный морфизм объединенной продукции.
Определение
98.
Объединенная
продукция.
Пусть
e1
e2
p1 ¬¾¾ p0 ¾¾® p2 – синхронизированные продукции с pi:Li→Ri
p
® R сопри i=0, 1, 2. Объединенная продукция p1 Å p0 p2 : L ¾¾
стоит из имени продукции p1 Å p0 p2 и соответствующего частичного морфизма p. На рис. 65 показана продукция p1 Å p0 p2 , где
2* 1*
2* 1*
< eL
, eL > и < eR
, eR > – универсальные квадраты соответственp
1 2
2
но < eL , eL > и < e1R , eR
>, L ¾¾
® R получено через универсальный
2*
2*
морфизм, удовлетворяющий p  e1L* = e1R*  p1 и p  eL
= eR
 p2 .
L0
e1L
R0
p0
eL2
L2
R2
p2
p1
L1
e1R*
R1
e1L*
eL2*
eR2
e1R
2*
eR
p
L
R
Рис. 65. Объединенная продукция
L0
e1L
e1R
L2
L1
R0
p0
eL2
eL2*
R2
p2
p1
e1L*
R1
p
L
eR2
e1R*
2*
eR
R
m2
m1
m1 Å m2
(m1 Å m2 )*
G
Рис. 66. Объединенный вывод
174
X
Определение 99. Объединенный вывод. Прямой вывод
p Å
p
1 p0 2
G ¾¾¾¾®
X,
m
использующий
объединенную
продукцию
p1 Å p0 p2 , носит название объединенного вывода. Со ссылками
2*
на морфизмы m1 = m  eL
и m2 = m  e1L* используется запись
p Å
p
1 p0 2
G ¾¾¾¾®
X.
m1 Åm2
Распределенный граф моделирует состояние исходного графа, разделенного на подграфы с общим интерфейсом. «Склейка» подграфов по их интерфейсам возвращает граф в исходное
состояние. Ниже эти идеи формализуются для двух локальных
состояний, относящихся к одному интерфейсу.
Определение 100. Распределенный граф. Распределенg1
g2
ный граф DG = (G1 ¬¾
¾ G0 ¾¾
® G2 ) состоит из двух локальных графов G1 и G2 и интерфейсного графа G0, а также графовых морфизмов g1 и g2, которые встраивают интерфейсный
граф в соответствующий локальный граф. Глобальный граф
G = ÅDG = G1 ÅG0 G2 распределенного графа DG определяется
как целевой объект универсального квадрата морфизмов g1 и g2
(рис. 67). Распределенный граф DG тотально разделяет граф G,
если графовые морфизмы g1 и g2 являются тотальными, иначе
DG – частично разделяющий распределенный граф.
(
H
H
H
H
(
(
( „( (
Рис. 67. Построение глобального графа
Частичное разбиение моделирует несогласованное распределенное состояние, например, если имеются висящие ссылки между локальными подсостояниями. В этой ситуации невозможно сделать однозначный вывод о принадлежности некоторых компонент
распределенного графа к глобальному графу. При построении глобального графа как целевого объекта универсального квадрата подобные вопросы разрешаются в пользу удаления несогласованных
компонент. Распределенные графы могут быть преобразованы с
175
помощью синхронизированных продукций, которые определяют
одновременные изменения всех локальных графов.
Определение
101.
Распределенный
вывод.
Пусть
g1
g2
mi
DG = (G1 ¬¾
¾ G0 ¾¾
® G2 ) – распределенный граф и Li ¾¾
® Gi
при i∈{0, 1, 2} – соответствия для синхронизированной продукe1
e2
ций p1 ¬¾¾ p0 ¾¾® p2 (рис. 68). Соответствия (mi )iÎ{0,1,2} форe1
e2
мируют распределенное соответствие для p1 ¬¾¾ p0 ¾¾® p2 в
DG, если gk  m0 = mk  eLk для k∈{1,2}. В этом случае распредеh1
h2
ленный вывод d1 ||d0 d2 : DG ® DH с DH = (H1 ¬¾
¾ H0 ¾¾
® H2 )
p1
порождается из локальных прямых выводов d1 = (G1 ¾¾® H1 ) и
m1
p
m0
p
m2
2
0
d2 = (G2 ¾¾®
H2 ) и интерфейсного вывода d0 = (G0 ¾¾®
H0 ) .
Частичные морфизмы h1 и h2 порождаются на основе универсального свойства универсального квадрата < p0* ,m0* >< p0 ,m0 >, согласно которому левые и нижние квадраты диаграммы на рис. 69
являются коммутативными. Если g1 и g2, так же, как и h1 и h2, тотальны, говорят о синхронном распределенном выводе d1 ||d0 d2 .
-
N
-
Q
N
-
N
(
3
Q
Q
(
(
Q
Q
3
3
N )
Q
N
)
N
)
Рис. 68. Распределенный вывод
Распределенный граф становится несогласованным (т. е. частично разделенным) при удалении элемента локального графа,
который имеет прообраз в интерфейсном графе.
Рассмотрим отношения между распределенным и объединенным выводами. Процесс объединения распределенного вывода
состоит в глобализации рассмотрения локальных действий. Возможность этого существует лишь в случае отсутствия противоречивости в глобальном описании, по крайней мере, данного
распределенного состояния DG. С другой стороны, распреде176
ление объединенного вывода означает разделение глобального
действия на несколько локальных. Следовательно, соответствия
элементарных продукций должны быть совместимыми с разделением глобального графа.
-
-L
N
NL
(
3
Q
L
F-
Q
Q
HL
L
3L
N
NL
)
(L
L
F3
QL
IL
)L
Рис. 69. Результат распределенного вывода
g
g
1
2
Теорема 5. Распределение. Пусть DG = (G1 ¬¾
¾ G0 ¾¾
® G2 ) –
1
2
e
e
тотальное разделение графа G=⊕DG, p1 ¬¾¾ p0 ¾¾® p2 – синхронизированные продукции, а p1 Å p0 p2 – их объединенная
продукция. В этом случае следующие высказывания являются
эквивалентными:
p1 Å p0 p2
H и распре1) существует объединенный вывод G ¾¾¾¾®
e1
m
e2
деленное соответствие (mi )iÎ{0,1,2} для p1 ¬¾¾ p0 ¾¾® p2 в DG,
2*
которое совместимо с m, т. е. g2*  m1 = m  eL
и g1*  m2 = m  e1L* ;
2) существует распределенный вывод d1 ||d0 d2 : DG ® DH с
p
mi
i
di = (Gi ¾¾
® Hi ) при i∈{0,1,2}.
Доказательство. См. [127].
Концепции объединенных и распределенных продукций можно обобщить для случаев с произвольным количеством элементарных продукций [128].
Условные преобразования графов
Благодаря использованию условий преобразования появляется возможность описать, в каких именно случаях исходные графы можно преобразовать к целевым. Идея состоит в рассмотрении левой части продукции не как одного графа L, а как граф L и
l
множество, объединенное морфизмами L ¾¾
® L ¢, которые носят
название ограничений. Для каждого ограничения L’ – (l)L отражает запрещенную структуру. Соответствие удовлетворяет ограничению, если оно не может быть расширено до запрещенного
177
графа L’, т. е. если запрещенные элементы не существуют в контексте соответствия. Если ограничение неинъективно и сюръективно, т. е. запрещенная структура вырождена, но элементы
L идентифицируются с помощью l, то соответствие не должно
идентифицировать эти элементы. Поэтому отрицательные ограничения могут использоваться для описания требований инъективности соответствия. Соответствие удовлетворяет отрицательному условию применения продукции, если оно удовлетворяет
всем ограничениям, из которых состоит отрицательное условие.
Существует несколько работ, посвященных методике использования условий при перезаписи графов [116, 117, 119].
Исторически введение положительных условий перезаписи
предшествовало использованию негативных условий. В работе
[117] доказывается повышение качества формального описания
и выразительности с помощью введения негативных условий
перезаписи графов. В этой же работе показано, что использование контекстно-свободных графовых грамматик с негативными
предусловиями дает больше возможностей, чем описание с помощью обычных контекстно-свободных графовых грамматик,
но уступает по выразительной силе применению контекстнозависимых графовых грамматик. В работе было введено понятие
постусловия, что также сделало аппарат описания перезаписи
графов более выразительным.
Условная перезапись графа является перезаписью графа, в которой каждая продукция p:L→R содержит множество условий.
Последние разделяются на подмножества предусловий и постусловий. Предусловия описывают ограничения, несоблюдение
которых ведет к невозможности выполнения продукции, постусловия – ограничения, которым должен удовлетворять результирующий граф после выполнения продукции.
Подмножества пред- и постусловий состоят из подмножеств
позитивных и негативных условий. Позитивные условия описывают «положительные» ограничения для L или R и обычно состоят в требовании существования некоторых вершин или ребер
для того, чтобы можно было выполнить продукцию. Обратно негативные условия вносят требования об отсутствии некоторых
вершин или ребер в L или R.
Понятие условия
Определение 102. Графовое ограничение. Атомарное графовое ограничение имеет вид PC(a) или NC(a) (соответственно поло178
жительное или отрицательное атомарное графовое ограничение),
где a:P→C – некоторый графовый морфизм. Графовое ограничение представляет собой булеву формулу, операндами которой являются атомарные графовые ограничения. Таким образом:
1) атомарное графовое ограничение является графовым ограничением;
2) если c – графовое ограничение, то и ¬c – графовое ограничение;
3) для любого индексированного множества I и любого семейства графовых ограничений (ci)i∈I, ∧i∈I ci и ∨i∈I ci – графовые ограничения.
Граф G удовлетворяет ограничениям PC(a) (NC(a)), записывается G|=PC(a) (G|=NC(a)), если для любого инъективного морфизма p:P→G существует (не существует) инъективный морфизм
q:C→G, такой, что q°a=p.
B
1
$
R
Q
(
B
1
$
R
Q
(
Рис. 70. Выполнимость атомарных ограничений
Граф G удовлетворяет ограничению ¬c, записывается G|=¬c,
если и только если граф G не удовлетворяет ограничению c. Граф
G удовлетворяет ограничению ∧i∈I ci (∨i∈I ci), записывается G|=∧i∈I
ci (G|=∨i∈I ci), если и только если G удовлетворяет всем (хотя бы
одному) ограничениям ci,i∈I.
Таблица 21
Примеры графовых ограничений
Формула
Интерпретация
PC(v ® vi : $ej : s(ej ) = t(ej ) = vi )
Существует, по крайней мере,
одна вершина
Каждая вершина имеет петлю
NC(v ® vi : $ej : s(ej ) = t(ej ) = vi )
В графе не имеется петель
ØPC(v ® vi : $ej : s(ej ) = t(ej ) = vi )
Существует вершина без петли
PC(® vi : $ej : s(ej ) = t(ej ) = vi )
Существует вершина с петлей
NC(v ® vi : $ej : s(ej ) = t(ej ) = vi )
Не существует вершин с петлями
PC(vi ,vj ® v)
179
Условия применения перезаписи графов впервые были представлены в работе [120]. Последующая работа [117] была посвящена графической нотации для описания условной перезаписи
графов. В работе [118] рассмотрено так называемое условное применение условий.
Лемма 20. Об инъективности ограничений. Имеют место следующие зависимости:
1) если a не инъективен и G|=PC(a), то p:P→G не инъективен;
2) если a не инъективен, то G|=NC(a).
Доказательство:
1) допустим инъективность p:P→G. Тогда G|=PC(a) порождает
существование инъективного q:C→G со свойством q°a=p. Из этого следует инъективность a;
2) допустим G|≠NC(a). Тогда существуют инъективные p:P→G
и q:C→G со свойством q°a=p. Из инъективности p следует инъективность a.
Определение 103. Условие применения. Атомарное условие применения над графом L имеет одну из следующих форм:
P(x, ∨i∈I xi), или P(x, ∧i∈I xi), где x:L→X – произвольный графовый морфизм и xi:X→Ci при i∈I являются инъективными графовыми морфизмами. Соответственно, говорят о положительных и
отрицательных условиях применения. Условие применения над
графом L является булевой формулой над атомарными условиями применения. Таким образом:
1) атомарное условие применения является условием применения;
2) если ac – условие применения, то и ¬ac – условие применения;
3) для любого индексированного множества I и любого семейства условий применения (aci)i∈I, ∧i∈I aci и ∨i∈I aci – условия применения.
L
x
m
X
xi
p
G
qi
Ci
Рис. 71. Выполнимость атомарных условий применения
Соответствие m:L→G удовлетворяет acL=P(x, ∨i∈I xi) (acL=N(x,
∧i∈I xi)), записывается m|=acL, если для каждого инъективного
180
морфизма p:X→G с p°x=m существует (не существует) такой i∈I
и инъективный морфизм qi:Ci→G, что qi°xi=p.
Соответствие m:L→G удовлетворяет условию применения вида
¬ac, записывается m|=¬ac, если и только если m не удовлетворяет условию применения ac. Соответствие m удовлетворяет ∧i∈I aci
(∨i∈I aci), записывается m|=∧i∈I aci (m|=∨i∈I aci), если и только если
m удовлетворяет всем (хотя бы одному) aci при i∈I.
Таблица 22
Примеры условий применения
для инъективного соответствия m:L→G
Формула
N (vi ,vj ® vi ,vj : $e : s(e) = vi Ù t(e) = vj )
Интерпретация
Не существует ребра из
вершины m(vi ) в вершину
m(vj )
Если существует ребро из
вершины m(vi ) в вершину
P(vi ,vj ® vi ,vj : $ek : s(ek ) = vi Ù t(ek ) = vj ®
m(vj ) , то существует и ребро
$el : s(el ) = vj Ù t(el ) = vi )
из вершины m(vj ) в вершину m(vi )
Определение 104. Продукция с условием применения. Продукция с условием применения, или условная продукция,
p
p ¢ : (L ¾¾
® R, ac( p)) состоит из имени продукции p’ и двойки –
частичного графового морфизма p и условия применения ac(p)
над графом L. Продукция является применимой к графу G при
m
L ¾¾
® G, если m удовлетворяет ac(p). В этом случае прямой
p
® H носит название прямого условного вывода
вывод G ¾¾
pˆ
m
G ¾¾
® H.
m
В случае условной продукции необходимо отличать предусловия от постусловий. Предусловия содержат ограничения на
L, поэтому называются левосторонними ограничениями; постусловия определяют ограничения на R и называются правосторонними ограничениями. Соблюдение условного вывода
p
G ¾¾
® H предусматривает соблюдение всех предусловий и всех
постусловий.
Определение 105. Пред- и постусловия. Условие ac(p) в
условной продукции разделяется на два подмножества –
ac(p)L-предусловий (условий применения над исходным графом)
и ac(p)R-постусловий (условий применения над результирующим
181
p̂
® H предуслографом). Для выполнения условного вывода G ¾¾
m
виям должно отвечать соответствие m в графе G, а постусловиям
должно отвечать косоответствие m* в графе H.
Лемма 21. Согласованность условий применения. Условие
применения ac над графом L является согласованным тогда и
только тогда, когда оно удовлетворяется idL.
Доказательство. Если idL удовлетворяет условию ac, то ac является согласованным условием. Допустим, idL не удовлетворяc
ет условию ac. Тогда существует ограничение L ¾¾
® L ¢ Î ac и тоk
тальный морфизм L ¢ ¾¾
® L , такой, что k°c=idL. Так как для люm
бого соответствия L ¾¾
® G соблюдается m=m°idL, то (m°k)°c=m,
т. е. m не удовлетворяет ограничению c∈ac, следовательно, и
условному применению ac.
Если два условия применения определены над одной и той же
левой частью продукции, их конъюнкция получается путем простого объединения. При необходимости расширить условия применений, определенные над L1 и L2, на граф L1+L2 используют
конструкцию универсального квадрата ограничения c и соответствия m.
m
Определение 106. Расширение. Если L ¾¾
® G – тотальный
c
морфизм и L ¾¾
® L ¢ – ограничение, тогда расширение me(c) ограничения c на m реализуется с помощью универсального квадрата
вида, представленного на рис. 72. Расширение условия применения ac над L определяется с помощью me(ac)={me(c):c∈ac}.
D
-a
Na
N
H
(a
-
(
U
O
,
Рис. 72. Расширение условия применения
m
Лемма 22. Расширение. Пусть L ¾¾
® G – тотальный морфизм, ac – условие применения над L. Тогда для всех соответt
ствий G ¾¾
® K, t|=me(ac), если и только если t°m|=ac.
182
Доказательство. Для каждого c∈ac тогда и только тогда
имеется t|=me(c), когда t°m|=c. Предположим, что диаграмма (2)
рис. 72 коммутативна. Тогда, в силу коммутативности (1) и (2),
n¢
n’=n°m’ и n’°c=m°t. Наоборот, пусть для L ¢ ¾¾
® K справедливо
n’°c=t°m. Тогда n, такой, что n°g=t, существует в силу свойства
универсальности (1).
В работе [134] показано, что любое постусловие может быть
преобразовано в соответствующие предусловия, что дает возможность проверки постусловия до выполнения продукции и используется для повышения эффективности перезаписи графов.
Лемма 23. Преобразование постусловия в предусловие. Для
p
p ¢ : (L ¾¾
® R, ac( p)) – условной продукции – и соответствия
m:L→G для любого c:R→R’∈ac(p)L существует α(c):L→L’ – упреp
® H, α(c) выполждающее условие, такое что для любого G ¾¾
m
p
® H тогда и только тогда, когда c выполняется в
няется в G ¾¾
p
m
G ¾¾
® H.
m
При использовании условных продукций определения последовательной композиции, продукций вывода и составных продукций должны быть уточнены. Необходимо учитывать условия, наp1
p2
пример, если p'1 : (L1 ¾¾
® R1, ac( p1 )) и p'2 : (L2 ¾¾
® R2 , ac( p2 ))
являются условными продукциями с R1=L2, их последовательная композиция p’1;p’2:L1→R2 определяется обычным способом,
с дополнительными условиями ac(p’1;p’2)L=ac(p2)R и ac(p1;p2)L,
полученной из ac(p1)L с помощью объединения всех постусловий
p1 и всех предусловий p2. Продукции вывода могут определяться
с помощью встраивания всех условий в обобщенный контекст.
Составные условные продукции определяются комбинацией
предыдущих способов.
Имеются две альтернативы описания условий – с помощью
графической нотации (как например в [132]) или с помощью формулы. Мы отдадим предпочтение текстовому описанию в идее
формулы в силу его компактности.
4.1.2. Формальное описание
преобразований программных средств
Для представления программных артефактов будут использоваться (L,A)-помеченные T-типизированные графы, в которых
T представляет собой фиксированный типовый граф, L – конечное множество меток и A – потенциально бесконечное множество ролей. Иными словами, будет использоваться категория
183
LTGraph или одна из ее подкатегорий. В рамках моделирования
преобразований ПС будут использоваться условные продукции,
результат применения которых не обязательно единственен.
p
Если G ¾¾
® H является выводом, соответствующим продукции
p:L→R, то G может иметь более одного подграфа, соответствующего левой части продукции L. Для каждой такой соответствующей части генерируется свой результирующий граф H.
Для формального описания преобразований ПС будут использоваться только инъективные тотальные соответствия m:L→G и
инъективные продукции p:L→R. По умолчанию будут использоваться преобразования, сохраняющие метки и типы, т. е. морфизмы категории LTGraphLT. В силу требования инъективности,
выполнение условной продукции p:L→R над графом G всегда будет приводить к уникальному результирующему графу H. Вывод
p
G ¾¾
® H является инъективным, а косоответствие m* – тотальным, в силу инъективности и тотальности соответствия m.
Элементарные преобразования
Помеченный граф, моделирующий ПС, может изменяться
различными способами. Каждое преобразование будет соответствовать некоторой условной продукции. С целью уменьшения
сложности описания этого процесса все возможные пути преобразований будут описываться с помощью конечного множества
элементарных продукций. В сравнении с работами [145, 146],
предлагаемый подход носит более ортогональный характер, что
позволяет комбинировать элементарные преобразования в составные.
Набор элементарных преобразований следует из структуры
графа, моделирующего ПС. Над этим графом можно осуществлять следующие виды преобразований: добавлять или удалять
вершины и ребра, изменять метки или типы вершин и ребер. Эти
преобразования формируют множество из восьми элементарных
преобразований:
1) добавление вершины – InsertV;
2) добавление ребра – InsertE;
3) удаление вершины – DropV;
4) удаление ребра – DropE;
5) изменение типа вершины – RetypeV;
6) изменение типа ребра – RetypeE;
7) изменение метки вершины – RelabelV;
184
8) изменение метки ребра – RelabelE.
Первые четыре преобразования были введены в работе [130],
правда, в несколько менее обобщенном виде.
Эти четыре преобразования формируют базис преобразований, так как остальные четыре могут быть выражены с помощью них. Более того, только преобразования с 1 по 4 относятся
к категории LTGraphLT, т. е. в рамках только этих преобразований сохраняются и типы, и метки. Преобразования 5 и 6 относятся к категории LTGraphL, а последние два – к категории
LTGraphT. Таким образом, первые четыре преобразования не нарушают типы и метки графа и являются достаточными для описания любого типа преобразования. Причина, обуславливающая
включение последних четырех преобразований, всецело лежит
в практической плоскости. Для достаточно сложной структуры графа ПС реализация, например, операции преобразования
типа вершины, выраженный с помощью удаления вершины существующего типа и введение вершины с новым типом, может
потребовать большого количества вспомогательных преобразований в силу необходимости выполнения набора предусловий,
запрещающего в данном случае наличие входящих и исходящих
ребер, соединенных с удаляемой вершиной.
Определение 107. Элементарные преобразования. Элементарные преобразования являются условными продукциями и
образуют множество Pe={InsertV, InsertE, DropV, DropE, RetypeV,
RetypeE, RelabelV, RelabelE}. Элементами множества являются:
1) условная
продукция
добавления
вершины
–
InsertV(v,t)∈LTGraphLT (где v и t – соответственно метка и тип
добавляемой вершины), имеющая предусловие (v,t)∉VL и постусловие (v,t)∈VR;
2) условная
продукция
добавления
ребра
–
InsertE(e,v,w,r)∈LTGraphLT (где e и r – соответственно метка и
тип добавляемого ребра, v и w – соответственно начальная и конечная вершины для ребра (s(e)=v, t(e)=w)), имеющая предусловие v∈VL∧w∈VL∧(e,v,w,r)∉EL и постусловие (e,v,w,r)∈ER;
3) условная
продукция
удаления
вершины
–
DropV(v,t)∈LTGraphLT,
имеющая
предусловие
(v,t)∈VL
∧AL(v,t)=∅ и постусловие (v,t)∉VR;
4) условная
продукция
удаления
ребра
–
DropE(e,v,w,r)∈LTGraphLT, имеющая предусловие (e,v,w,r)∈EL
и постусловие (e,v,w,r)∉ER;
185
5) условная продукция изменения типа вершины –
RetypeV(v,t1,t2)∈LTGraphL (где v, t1 и t2 – соответственно метка,
существующий и новый тип вершины), имеющая предусловие
(v,t1)∈VL∧(v,t2)∉VL и постусловие (v,t2)∈VR∧(v,t1)∉VR;
6) условная
продукция
изменения
типа
ребра
–
RetypeE(e,v,w,r1,r2)∈LTGraphL (где e, r1 и r2 – соответственно метка, существующий и новый тип ребра), имеющая предусловие (e,v,w,r1)∈EL∧(e,v,w,r2)∉EL и постусловие
(e,v,w,r2)∈ER∧(e,v,w,r1)∉ER;
7) условная продукция изменения метки вершины –
RelabelV(v1,t,v2)∈LTGraphT (где v1, v2 и t – соответственно существующая, новая метка и тип вершины), имеющая предусловие
(v1,t)∈VL∧(v2,t)∉VL и постусловие (v2,t)∈VR∧(v1,t)∉VR;
8) условная продукция изменения метки ребра –
RelabelE(e1,v,w,r,e2)∈LTGraphT (где e1, v, w, r и e2 – соответственно существующая метка, начальная, конечная вершины, тип ребра и его новая метка), имеющая
предусловие
(e1,v,w,r)∈EL∧(e2,v,w,r2)∉EL
и
постусловие
(e2,v,w,r)∈ER∧(e1,v,w,r2)∉ER.
Лемма 24. Базис элементарных преобразований образует множество Pb={InsertV, InsertE, DropV, DropE}.
Доказательство. Для доказательства приведем определения
четырех элементарных преобразований, не входящих в базис, с
помощью базисных элементарных преобразований:
– RetypeV(v,t1,t2) = DropV(v,t1)°InsertV(v,t2);
– RetypeE(e,v,w,r1,r2) = DropE(e,v,w,r1)°InsertE(e,v,w,r2);
– RelabelV(v1,t,v2) = DropV(v1,t)°InsertV(v2,t);
– RelabelE(e1,v,w,r,e2) = DropE(e1,v,w,r)°InsertE(e2,v,w,r).
При описании элементарных преобразований не учитывались
аксиомы, связанные с типами вершин и ребер. Для их учета необходимо расширить постусловия преобразований – элементарное
преобразование может быть выполнено только в том случае, если
результирующий граф удовлетворяет аксиомам типов вершин и
ребер. Выполнение этого условия гарантируется требованием,
согласно которому все графы системы должны иметь одинаковый типовый граф.
Необходимо иметь в виду, что и предусловия, и постусловия
сформулированы независимо от контекста применения преобразований. При использовании формализма в рамках конкретной
области моделирования необходимо расширить аксиомы типов и
186
условия преобразований дополнительными выражениями, учитывающими особенности этой области. С теоретической точки
зрения, описание постусловий преобразований представляется
избыточным, так как их можно выразить с помощью соответствующих предусловий. Однако на практике часто бывает удобно описывать постусловия преобразований непосредственно.
Обратные элементарные преобразования
В силу свойства инъективности элементарных преобразований, каждому из них можно сопоставить обратное элементарное
преобразование.
Определение 108. Обратные элементарные преобразования.
Для элементарного преобразования (p:L→R, ac(p)), (p–1:L→R,
ac(p–1)) является обратным элементарным преобразованием,
если ac(p)L= ac(p–1)R и ac(p)R= ac(p–1)L.
Это определение соответствует теоретико-категорному определению инверсии, так как если p–1 – инверсия p, то p°p–1=(idR:R→R,
ac(p)R)и p–1°p=(idL:L→L, ac(p)L).
Лемма 25. Обратные отношения элементарных преобразований. Каждое введенное элементарное преобразование имеет соответствующее обратное элементарное преобразование:
1)  Insert-1 (v,t) = DropV (v,t), и наоборот;
V
2)  Insert-1 (e,v,w,r ) = Drop E (e,v,w,r ), и наоборот;
E
3)  Retype-1 (v,t1,t2 ) = Retype V (v,t2 ,t1 );
V
4)  Retype-1 (e,v,w,r1,r2 ) = Retype E (e,v,w,r2 ,r1 );
E
5)  Relabel-1 (v1,t,v2 ) = Relabel V (v2 ,t,v1 );
V
6)  Relabel-1 (e1,v,w,r , e2 ) = Relabel E (e2 ,v,w,r , e1 ).
E
Доказательство. Доказательство следует из того факта, что
для каждой двойки взаимно обратных элементарных преобразований предусловие первого преобразования совпадает с постусловием обратного к нему.
Составные преобразования
Из элементарных преобразований может быть образована последовательность, за несколько шагов приводящая граф из начального в конечное состояние. Последовательность из n элементарных преобразований требует для своего выполнения формирования n–1 промежуточных графов. Альтернативным вариантом является объединение нескольких элементарных преобразований в составные, которые консолидируют все преобразования
187
графа в одной продукции и рассматриваются в этом смысле как
атомарные. В этом случае необходимость вывода промежуточных графов отпадает, что делает процесс преобразования более
эффективным.
Определение 109. Составные преобразования. Пусть G0 и Gn –
два графа и G0 →+ Gn – последовательность условных выводов, таp1
p2
pn
кая, что G0 ¾¾
® G1 ¾¾
® ¾¾
® Gn при n≥2 и ∀i∈{1..n}:pi – элементарное преобразование. Составное преобразование pC представляет собой композицию условных продукций pC=p1°p2°…°pn:
G0→Gn.
Однотипные составные преобразования
Особым классом составных преобразований являются однотипные, т. е. такие составные преобразования, которые представляют собой композицию элементарных преобразований одного
типа. Композицию однотипных преобразований, образующих
базис, выделяет одно общее свойство – порядок выполнения элементарных преобразований не имеет значения.
Определение 110. Однотипные составные преобразования.
Составное преобразование pC=p1°p2°…°pn: G0→Gn является однотипным, если все p…pn являются элементарными преобразованиями одного типа. Соответственно типам элементарных преобразований, существуют восемь типов однотипных составных
преобразований:
1) композиция добавлений вершин – pCIV=InsertV°…°InsertV;
2) композиция добавлений ребер – pCIE=InsertE°…°InsertE;
3) композиция удалений вершин – pCDV=DropV°…°DropV;
4) композиция удалений ребер – pCDE=DropE°…°DropE;
5) композиция изменений типов вершин – pCTV=RetypeV°…
Retype
°
V;
6) композиция изменений типов ребер – pCTE=RetypeE°…
°RetypeE;
7) композиция изменений меток вершин – pCLV=RelabelV°…
Relabel
°
V;
8) композиция изменений меток ребер – pCLE=RelabelE°…
°RelabelE.
Основным ограничением однотипных составных преобразований, полученных из базисных элементарных преобразований,
является запрет на дублирование элементарных преобразований (например, связанных с введением вершины с одинаковыми
меткой и типом). При этом типы и метки вершин и ребер могут
188
изменяться в рамках одного составного преобразования неоднократно.
Лемма 26. Объединение базисных преобразований. Не существует возможности объединить в составное преобразование одинаковые базисные элементарные преобразования. Более точно,
pC
для G0 ¾¾
® Gn , i,j∈{1..n} должно выполняться:
1) для ∀pi=InsertV(va,ta)∈pCIV и ∀pj=InsertV(vb,tb)∈pCIV, из a=b
следует i=j;
2) для ∀pi=InsertE(ea,v,w,ra)∈pCIE и ∀pj=InsertE(eb,v,w,rb)∈pCIE,
из a=b следует i=j;
3) для ∀pi=DropV(va,ta)∈pCDV и ∀pj=DropV(vb,tb)∈pCDV, из a=b
следует i=j;
4) для ∀pi=DropE(ea,v,w,ra)∈pCDE и ∀pj=DropE(eb,v,w,rb)∈pCDE,
из a=b следует i=j.
Доказательство:
1) пусть
pCIV=p1°…°pn,
i,j∈{1..n}:i<j,
pi=InsertV(v,t),
pj=InsertV(v,t). Тогда pCIV не может являться составным преобразованием, так как для преобразования pj не будет выполнено
предусловие (v,t) Ï VLj Í ac( pj )L в силу существования постусловия (v,t) Î VLi Í ac( pi )R ;
2) для составных преобразований pCIE, pCDV, pCDE доказательство аналогично 1).
Композицию однотипных преобразований, образующих базис, выделяет одно общее свойство – порядок выполнения элементарных преобразований не имеет значения.
Лемма 27. Независимость порядка выполнения композиции
базисных преобразований. Для составного однотипного преобразования, полученного с помощью композиции базисных элементарных преобразований, порядок выполнения элементарных
преобразований значения не имеет и ведет всегда к одному и тому
же результату.
Доказательство. Покажем, что при выполнении элементарных преобразований однотипного составного преобразования pС=p1°p2, p1=InsertV(v1,t1), p2=InsertV(v2,t2) порядок значеp2
ния не имеет. Если v1≠v2, то продукция G1 ¾¾
® G2 является
p1
последовательно независимой от продукции G0 ¾¾
® G1, так
как предусловие ac( p2 )L = (v2 ,t2 ) Ï VL2 не затрагивается продукцией p1, в силу того, что эта продукция не удаляет вершиp1
ны. Аналогично, G0 ¾¾
® G1 слабо зависит от p2, так как предусловие ac( p1 )L = (v1,t1 ) Ï VL1 не нарушается, в силу того, что p2
189
вводит вершину v2, отличную от v2. Очевиден вывод о том, что
p1
p2
G0 ¾¾
® G1 и G1 ¾¾
® G2 представляют собой последовательно
p1
p2
независимые продукции, следовательно, G0 ¾¾
® G1 ¾¾
® G2 –
последовательно независимый условный вывод. Аналогично
доказывается последовательная независимость однотипного составного преобразования, состоящего из InsertE, DropV и DropE.
Если последовательность состоит из более чем двух элементарных преобразований, достаточно показать последовательную
независимость каждой пары преобразований. В силу последовательной независимости составных однотипных преобразований,
на основе базисных элементарных преобразований можно сделать важный вывод о возможности произвольного порядка применения базисных преобразований в рамках последовательности
и о совпадении результирующего графа при любом порядке применения преобразований.
Слабо последовательно независимые
составные преобразования
Совокупность однотипных базисных элементарных преобразований является последовательно независимой. Для выявления
фактов независимости других видов композиции преобразований будет использоваться термин слабой последовательной независимости.
Определение 111. Слабая последовательная независимость. Элементарное преобразование p2 слабопоследовательно
не зависит от элементарного преобразования p1 в композиции
p1
p2
G0 ¾¾
® G1 ¾¾
® G2 в том и только в том случае, если p1 не влияет на предусловие ac(p2)L.
Понятие слабой последовательной независимости отвечает
на вопрос о том, может ли преобразование p2 выполняться после
преобразования p1. Таким образом, в правильно упорядоченной
последовательности преобразований, согласно их слабой независимости, перед выполнением каждого преобразования необходимо проверить выполнение соответствующего ему предусловия.
В табл. 23 в строках расположены типы i-го преобразования, в
столбцах – i+1. В ячейках символом «*» обозначена безусловная
независимость преобразований, формулы отражают предусловия, чьи истинные значения необходимы для выполнения свойства слабой последовательной независимости преобразований
pi+1 и pi.
190
Таблица 23
Зависимости составных преобразований
(t2≠q)∨
(v2≠w)
RelabelE
(e1,c,d,r,e2)
RelabelV
(v1,t,v2)
RetypeE
(e,c,d,r1,r2)
RetypeV
(v,t1,t2)
DropE
(e,c,d,r)
(t≠q)∨
(v≠w)
DropV
(v,t)
InsertV
(w,q)
InsertE
(e,c,d,r)
p1
InsertV
(v,t)
p2
(t≠q)∨
(v2≠w)
InsertE
(f,a,b,p)
(r≠p)∨
(e≠f)∨
(a≠c)∨
(b≠d)
(r2≠p)∨
(a≠c)∨
(b≠d)
(r≠p)∨
(e2≠f)∨
(a≠c)∨
(b≠d)
DropV
(w,q)
(w≠c)∧ (t≠q)∨ (w≠c) ∧ (t1≠q)∨
(w≠d) (w≠v) (w≠d) (w≠v)
(w≠c) ∧ (t≠q)∨
(w≠d) (w≠v1)
(w≠c) ∧
(w≠d)
(f≠e)∨
(a≠c)∨
(b≠d)∨
(p≠r1)
(f≠e1)∨
(a≠c)∨
(b≠d)∨
(p≠r)
DropE
(f,a,b,p)
(f≠e)∨
(a≠c)∨
(b≠d)∨
(p≠r)
RetypeV
(w,q1,q2)
(t≠q2)∨
(v≠w)
RetypeE
(f,a,b,p1,p2)
RelabelV
(w1,q,w2)
(r≠p2)∨
(e≠f)∨
(a≠c)∨
(b≠d)
(t≠q)∨
(v≠w2)
RelabelE
(f1,a,b,p,f2)
(t1≠q1)∨
(v≠w)
(t≠q1)∨
(v≠w)
(r1≠p1)∨
(e≠f)∨
(a≠c)∨
(b≠d)
(r≠p1)∨
(e≠f)∨
(a≠c)∨
(b≠d)
(t1≠q)∨
(v≠w1)
(t≠q)∨
(v≠w1)
(r≠p)∨
(e≠f2)∨
(a≠c)∨
(b≠d)
(t1≠q2)∨
(v2≠w)
(r≠p)∨
(e≠f1)∨
(a≠c)∨
(b≠d)
(r≠p1)∨
(e1≠f)∨
(a≠c)∨
(b≠d)
(t≠q)∨
(v1≠w1)
(r1≠p)∨
(e≠f2)∨
(a≠c)∨
(b≠d)
(r≠p)∨
(e1≠f1)∨
(a≠c)∨
(b≠d)
Взаимное поглощение элементарных преобразований
Определение 112. Взаимопоглощающие элементарные преобразования. Пара элементарные преобразования pi и pi+1, вхоp1
pn
дящие в составное преобразование G0 ¾¾
®… ¾¾
® Gn , называются взаимопоглощающими в том и только в том случае, если
выполняется ( pi = pi-+11 ) Ú ( pi-1 = pi+1 ).
Взаимопоглощающие преобразования могут быть исключены
из составного преобразования.
191
Лемма 28. Исключение взаимопоглощающих преобразоваp1
p2
ний. Пусть G0 ¾¾
® G1 ¾¾
® G2 , если (p1,p2) являются взаимопоглощающими, то G0=G2.
Доказательство.
В
силу
уникальности
результата элементарного преобразования, обеспечиваемого использованием
инъективных
морфизмов,
выполняется
p-1
p
1
2
G1 ¾¾¾
® G0 Þ G1 ¾¾
® G0 Þ G2 = G0 .
Лемма 29. Уникальность составных преобразований.
Исключение
взаимопоглощающих
преобразований
(pi,
p1
pn
pi+1) в составном преобразовании G0 ¾¾
®… ¾¾
® Gn позволяет получить уникальное составное преобразование
pi +2
p1
pi-1
pn
G0 ¾¾
®… ¾¾¾
® G ¢ ¾¾¾
®… ¾¾
® Gn , в котором G’=Gi-1=Gi+1.
Доказательство.
Согласно
лемме
об
уникальности составных преобразований, Gi-1=Gi+1, следовательно, есть возможность замены составного преобразования
pi +1
pi +2
p1
pi-1
pi
pn
G0 ¾¾
®… ¾¾¾
® Gi-1 ¾¾
® Gi ¾¾¾
® Gi+1 ¾¾¾
®… ¾¾
® Gn
pi +2
p1
pi-1
pn
на G0 ¾¾
®… ¾¾¾
® G ¢ ¾¾¾
®… ¾¾
® Gn . Для доказательства уникальности полученного таким образом преобразования предположим, что и (pi, pi+1), и (pi+1, pi+2) являются взаимопоглощающими. В этом случае результатом исключения преобразований явятся или составное преобpi +2
p1
pi-1
pn
разование
G0 ¾¾
®… ¾¾¾
® Gi-1 ¾¾¾
®… ¾¾
® Gn ,
или
pi +3
p1
pi-1
pi
pn
G0 ¾¾®… ¾¾¾
® Gi-1 ¾¾® Gi+2 ¾¾¾
®… ¾¾® Gn . Тогда выполняется ( pi = pi-+11 ) Ù ( pi+1 = pi-+12 ) Þ pi = ( pi-+12 )-1 = pi+2 .
Абсорбирующие элементарные преобразования
Определение 113. Абсорбирующие элементарные преобраp1
pn
зования. Пусть G0 ¾¾
®… ¾¾
® Gn – составное преобразование.
Элементарное преобразование pi¢ называется абсорбирующим
для композиции преобразований pi°pi+1, если имеет место:
1) ( pi = DropV (v,t1 )) Ù ( pi+1 = InsertV (v,t2 )) Ù ( pi¢ = Retype V (v,t1,t2 ));
2) ( pi = InsertV (v,t1 )) Ù ( pi+1 = Retype V (v,t1,t2 )) Ù ( pi¢ = InsertV (v,t2 ));
3) ( pi = Retype V (v,t1,t2 )) Ù ( pi+1 = DropV (v,t2 )) Ù ( pi¢ = DropV (v,t1 ));
4) ( pi = Retype V (v,t1,t2 )) Ù ( pi+1 = Retype V (v,t2 ,t3 )) Ù ( pi¢ =
= Retype V (v,t1,t3 ));
5) ( pi = Relabel V (v1,t,v2 )) Ù ( pi+1 = DropV (v2 ,t)) Ù ( pi¢ = DropV (v1,t));
192
6) ( pi = Relabel V (v1,t,v2 )) Ù ( pi+1 = RelabelV (v2 ,t,v3 )) Ù ( pi¢ =
= Relabel V (v1,t,v3 ));
7) ( pi = Drop E (e,v,w,r1 )) Ù ( pi+1 = Insert E (e,v,w,r2 )) Ù ( pi¢ =
= Retype E (e,v,w,r1,r2 ));
8) ( pi = Insert E (e,v,w,r1 )) Ù ( pi+1 = Retype E (e,v,w,r1,r2 )) Ù ( pi¢ =
= Insert E (e,v,w,r2 ));
9) ( pi = Retype E (e,v,w,r1,r2 )) Ù ( pi+1 = Drop E (e,v,w,r2 )) Ù ( pi¢ =
= Drop E (e,v,w,r1 ));
10) ( pi = Retype E (e,v,w,r1,r2 )) Ù ( pi+1 = Retype E (e,v,w,r2 ,r3 )) Ù ( pi¢ =
= Retype E (e,v,w,r1,r3 ));
11) ( pi = Relabel E (e1,v,w,r,e2 )) Ù ( pi+1 = Drop E (e2 ,v,w,r )) Ù ( pi¢ =
= DropV (e1,v,w,r ));
12) ( pi = Relabel E (e1,v,w,r,e2 )) Ù ( pi+1 = Relabel E (e2 ,v,w,r ,e3 )) Ù ( pi¢ =
= Relabel E (e1,v,w,r , e3 )).
Все элементарные преобразования, соответствующие абсорбирующим, являются последовательно зависимыми. При этом
абсорбирующее преобразование pi¢ совпадает с композицией
преобразований pi°pi+1. Это свойство позволяет сформулировать
следующую лемму.
Лемма 30. Замена композиции абсорбирующим преобразованием. Замена композиции pi°pi+1, принадлежащей составному
p1
pn
преобразованию G0 ¾¾
®… ¾¾
® Gn , абсорбирующим преобразованием pi¢ порождает приведенное
составное преобразование
pi +2
p1
pi-1
pi¢
pn
G0 ¾¾
®… ¾¾¾
® Gi-1 ¾¾
® Gi+1 ¾¾¾
®… ¾¾
® Gn , которое после абсорбции всех соответствующих композиций становится
уникальным.
Доказательство. В силу того, что замена композиции
преобразований абсорбирующим преобразованием, в силу
pi¢ = pi  pi+1, не изменяет результирующего графа, достаточно рассмотреть соответствия пред- и постусловий композиции
и абсорбирующего преобразования для каждого типа соответствий определения 113. Например, если pi=RetypeV(v,t1,t2), то
ac(pi)L=((v,t1)∈Li), ac(pi)R=((v,t2)∈Ri); если pi+1=DropV(v,t2), то
ac( pi+1 )L = ((v,t2 ) Î Li+1 ) Ù ALi +1 (v,t2 ) = Æ, ac(pi+1)R=((v,t2)∉Ri+1).
Выполнение композиции pi°pi+1 порождает преобразование
pi¢ , имеющее ac( pi¢ )L¢ = ((v,t1 ) Î Li¢ ) Ù A ¢ (v,t1 ) = Æ и ac( pi¢ )R ¢ =
Li
= ((v,t1 ) Ï Ri¢ ). Следовательно, pi¢ = DropV (v,t1 ). Аналогичный
вывод справедлив для остальных типов преобразований.
193
Минимизация составных преобразований
Для преобразований RetypeV(v,t1,t2), RetypeE(e,c,d,r1,r2),
RelabelV(v1,t,v2) и RelabelE(e1,c,d,r,e2) целесообразно сформулировать следующее правило: любое составное преобразование для каждой вершины (ребра) должно содержать только по
одному преобразованию вида RetypeV(v,t1,t2) и RelabelV(v1,t,v2)
(RetypeE(e,c,d,r1,r2) и RelabelE(e1,c,d,r,e2)). С использованием
этого правила можно сформулировать понятие минимальной последовательности изменений типов и меток как вершин, так и
ребер.
Определение 114. Минимальная последовательность изменений типов и меток:
1) композиция изменений типов вершин pCTV является минимальной, если
"i, j : pi = Retype V (v,t1,t2 ), pj = Retype V (w,t3 ,t4 ),v = w Þ i = j;
2) композиция изменений типов ребер pCTE является минимальной, если
"i, j : pi = Retype E (e, a, b,r1,r2 ), pj = Retype E (f, c,d, p1, p2 ),(e, a, b) =
= (f, c,d) Þ i = j;
3) композиция изменений меток вершин pCLV является минимальной, если
"i, j : pi = Relabel V (v1,t,v2 ), pj = Relabel V (w1,q,w2 ),t = q Þ i = j;
4) композиция изменений меток ребер pCLE является минимальной, если
"i, j : pi = Relabel E (e1, a, b,r , e2 ), pj = Relabel E (f1, c,d, p, f2 ),(a, b,r ) =
= (c,d, p) Þ i = j.
Лемма 31. Минимизация составных изменений типов и меток вершин и ребер. Каждое составное преобразование вида pCTV,
pCTE, pCLV и pCLE может быть приведено к минимальному.
Доказательство. Для каждого из композиции однотипных
преобразований над одной вершиной (ребром), согласно определению 113, найдется соответствующее абсорбирующее преобразование. Последовательная замена композиции на абсорбирующее преобразование приведет к формированию уникального преобразования с минимальными pCTV, pCTE, pCLV и pCLE.
194
Обобщим результаты этого раздела для описания произвольного составного преобразования.
Определение 115. Минимальное составное преобразование.
p1
pn
Составное преобразование G0 ¾¾
®… ¾¾
® Gn называется минимальным, если для любой пары элементарных преобразований
(pi,pj), принадлежащих составному, не найдется соответствующего абсорбирующего преобразования pa=pi°pj.
Предопределенные составные преобразования
Введем некоторые другие виды предопределенных преобразований:
1) изменение направления ребра:
Redirect E (e,v,w,r ) = Drop E (e,v,w,r )  Insert E (e,w,v,r );
2) изменение начальной вершины ребра (с дополнительным
предусловием t(v1)=t(v2)):
Redirect ES (e,v1,w,r,v2 ) = Drop E (e,v1,w,r )  Insert E (e,v2 ,w,r );
3) изменение конечной вершины ребра (с дополнительным
предусловием t(w1)=t(w2)):
Redirect ET (e,v,w1,r,w2 ) = Drop E (e,v,w1,r )  Insert E (e,v,w2 ,r );
4) изменение начальной вершины группы ребер (с дополнительными предусловиями t(v1)=t(v2) и OEG(v1)={(e1,v1,w1,r1),…,
(en,vn,wn,rn)}):
Redirect ESG (v1,v2 ) =
= Redirect ES (e1,v1,r1,v2 )  Redirect ES (en ,v1,rn ,v2 );
5) изменение конечной вершины группы ребер (с дополнительными предусловиями t(w1)=t(w2)и IEG(w1)={(e1,v1,w1,r1),…,
(en,vn,wn,rn)):
Redirect ETG (w1,w2 ) =
= Redirect ET (e1,w1,r1,w2 )  Redirect ET (en ,w1,rn ,w2 ).
Остальные типы составных преобразований должны формироваться путем комбинации элементарных преобразований в зависимости от предметной области. Целесообразно сформировать
каталог предопределенных составных преобразований, каждое
из которых переводит ПС из одного состояния (например, дефектного) в другое (например, эталонное).
4.1.3. Операторы преобразований
на метрических пространствах
На метрических пространствах Mb вводятся операторы преобразований. Назначение операторов состоит в изменении значе195
ний базовых метрик путем преобразования графовой модели ПС.
Во множество таких операторов входят операторы добавления и
удаления вершины (ребра) для всех типов вершин и ребер.
Определение 116. Базовые операторы преобразований. Базовые операторы преобразований Atb:Mb→Mb соответствуют элементарным преобразованиям графовых моделей ПС, определяемым базисом Pb={InsertV,InsertE,DropV,DropE}.
Определение 117. Производные операторы преобразований.
Производные операторы преобразований Atd:Md→Md соответствуют составным преобразованиям графовых моделей ПС, определяемых композициями условных продукций вида pC=p1°p2°…
°pn:G0→Gn.
4.1.4. Моделирование преобразований ОО-кода
Графовое представление кода
В главе, посвященной моделированию ПС с помощью теории
графов, была представлена возможность описания Java-кода.
Напомним некоторые обозначения (табл. 1, 2; рис. 10) и продолжим описание в рамках моделирования преобразований используемого фрагмента кода.
Тело метода описывается с помощью структуры, состоящей
из Ex-помеченных вершин, соединенных ребрами, представляющих информацию о динамических вызовах, доступах и модификациях переменных. На рис. 73 представлена структура метода
myCreayeTimer класса TimerClassBean.
Продукции перезаписи графов
В общем случае для любого составного преобразования необходимо описывать параметризированные графовые продукции
и выполнять их последовательно. Для некоторых типичных составных преобразований вводятся шаблоны, позволяющие оптимально выполнять эти преобразования.
Для описания подхода к преобразованию допустим, что все
операции с переменными класса в коде примера необходимо
делать с помощью методов доступа и модификации (даже в методах того же класса). Обычно такому преобразованию соответствует шаблон EncapsulateField(var, accessor, updater). В рассматриваемом случае существует одна такая переменная (private
SessionContext context), причем метод для ее модификации уже
существует. Следовательно, в рамках преобразования необходимо:
196
Si
myCreateTimer
pa
Va
timer
Si
println
myCreateTimer
ex
ex
Ex
dy
ty
Ex
Ex
dy
Ex
dy
pa
co co
ex
ac
pa
ac
up
me
Bo
ty
Si
=
Ex
ac
Pa
me
up
Ex
dy
co
Ex
ty
Cl
Timer
Cl
TimerSessionBean
li
Pa
intervalDuration
Ty
long
me
co
Pa
me
li
Bo
createTimer
ac
pa
Ex
Si
createTimer
ac
dy
p t
Ex
Va
context
ac
pa
Pa
Cl
String
ty
Va
timerService
Si
getTimerService
Ex
pa
Cl
TimerService
ty
li
Bo
ty getTimerService
me
Cl
SessionContext
Рис. 73. Структура метода myCreayeTimer класса TimerClassBean
1) добавить метод для доступа к переменной context;
2) заменить выражение доступа к переменной context в методе myCreateTimer на выражение вызова добавленной в пункте 1
функции доступа.
На рис. 74 представлено (с сокращениями) состояние кода до
и после применения преобразования. Для реализации этого преобразования введем шаблон AddAccessor(var, accessor).
Будем использовать параметризованные графовые продукции, в которых продукции имеют переменные для меток графа.
С помощью присвоения значений этим переменным можно получить конкретный экземпляр продукции. На рис. 75 представлена продукция, имеющая в качестве параметров var и accessor.
Продукция на рис. 75 описывает преобразование AddAccessor(var, accessor). В этой продукции все вершины проиндексиро197
public class TimerSessionBean implements SessionBean, TimedObject {
private SessionContext context ;
public void myCreateTimer (long intervalDuration ) {
…
TimerService timerService = context.getTimerService ();
…
}
…
}
public class TimerSessionBean implements SessionBean, TimedObject {
private SessionContext context ;
public SessionContext getSessionContext () { return context; }
public void myCreateTimer (long intervalDuration ) {
…
TimerService timerService = getSessionContext ().getTimerService ();
…
}
…
}
Рис. 74. Преобразование кода
W
W
7B
WBS
7B
WBS
UZ W
UZ W
$M
$M
W
W
BD
&Y
FY
#P
BDDFTTPS
W
MJ
4J
BDDFTTPS
UZ
Рис. 75. Параметризированная продукция AddAccessor
ваны. Вершины, имеющие в левой и правой частях одинаковый
индекс, сохраняются в рамках продукции. Вершины с индексами, содержащиеся только в левой части, удаляются, а вершины
с индексами только в правой части создаются в рамках продукции.
С целью учета контекста применения продукции, состоящего из выражений относящихся к инкапсулируемой переменной,
продукции снабжаются механизмом встраивания, описанным
в [132]. Механизм встраивания описывает способ переориентации ребер. Входящие ребра, т. е. те, которые имеют в качестве
целевых вершины в левой части продукции и не имеют в ней
вершин-источников, переориентируются согласно входящим
ребрам, описанным в табл. 24. Например, (ac,v1)→(dy,v3) озна198
чает, что выражение доступа к переменной var (представленная
входящим ac-ребром к вершине v1) заменяется динамическим
вызовом метода доступа (представленного входящим dy-ребром
к вершине v3). Выходящие ребра обрабатываются аналогично. Например, (me,v1)→(me,v1),(me,v4) означает, что тело метода доступа (вершина v4) должно быть реализовано в том же
классе, в котором определена переменная var (вершина v1),
(ty,v1)→(ty,v1),(ty,v3),(ty,v6) означает, что тип значения, возвращаемый методом доступа, должен совпадать с типом переменной. Типовый граф на рис. 12 позволяет гарантировать, что табл.
24 является полной, так что все возможные типы входящих и
исходящих ребер покрыты. Поэтому, согласно типовому графу,
Va-вершина может иметь входящими только ac- и up-ребра и исходящими только me- и ty-ребра.
Таблица 24
Спецификация встраивания
Входящее ребро
Исходящее ребро
(ac,v1)→(dy,v3)
(me,v1)→(me,v1),(me,v4)
(ty,v1)→(ty,v1),(ty,v3),(ty,v6)
Основанная на механизме встраивания, параметризованная
продукция рис. 75 является спецификацией в бесконечном множестве продукций в алгебраическом подходе перезаписи графов
[120, 133, 134]. Конкретная продукция может быть получена из
параметризованной и основанной на встраивании путем:
1) присвоения параметрам параметризованной продукции
конкретных значений;
2) расширения левой и правой частей основанной на встраивании продукции конкретным контекстом.
На рис. 76 представлена продукция AddAccessor(var,accessor),
которая применяется к коду рис. 73. Заштрихованные Exвершины графа на рис. 76 совпадают с заштрихованной Exвершиной графа на рис. 74.
Сохранение поведения после преобразований
Графовое выражение Bo ¾¾¾
® Va может быть использовано
?*ac
для описания свойства сохранения доступа. Оно описывает все
возможные пути доступа из тела метода (Bo-вершины) к пере199
Cl
Cl
Cl
Cl
TimerSessionBean
SessionContext
TimerSessionBean
SessionContext
me
me
ty
Va
Va
context
ac
Ex
context
ac
Ex
ty
Ex
me
ex
ty
Bo
getSessionContext
dy
li
Si
getSessionContext
Рис. 76. Применение параметризованной продукции AddAccessor
менной (Va-вершине). Аксиомы, описываемые типовым графом,
гарантируют существование только одного ac-ребра в этом пути,
и это ребро является последним ребром пути. Сохранение доступа означает, что для каждого вхождения Bo ¾¾¾
® Va в началь?*ac
ный граф, предназначенный для перезаписи, имеется соответствующее вхождение этого выражения в результирующий граф,
соединяющий такие же Bo- и Va-вершины. Поэтому вершины,
совпадающие с Bo или Va, удалены или добавлены в рамках применения графовой продукции.
® Si ¾¾® Cl ¬¾¾
¾ Cl описывает
Графовое выражение Bo ¾¾¾
?*dy
me
ge*
Bo
¾¾¾
® Si описвойство сохранения вызова. Подвыражение
?*dy
сывает, что для каждого тела метода (Bo-вершины), в котором
выполняется динамический вызов (dy-ребро) некоторой сигнатуры (Si-вершина) в начальном графе, должен присутствовать аналогичный динамический вызов из этого же тела метода
этой же сигнатуры в результирующем графе. Подвыражение
Si ¾¾® Cl ¬¾¾
¾ Cl отражает тот факт, что сигнатура, определенme
ge*
ная в некотором классе, является доступной в рамках этого класса и всех его подклассов.
Покажем сохранение доступа для преобразования AddAccessor. Для этого достаточно доказать, что свойству Bo ¾¾¾
® Va
?*ac
удовлетворяют все тела методов Bo, которые получают доступ к
200
переменной var. Этот факт следует из формы продукции, представленной на рис. 75. Рис. 77 иллюстрирует замену непосредственного доступа к переменой var более длинным путем, который все еще удовлетворяет свойству Bo ¾¾¾
® Va.
?* ac
Аксиомы сохранения поведения
Помимо общего требования по соответствию аксиомам формальной корректности, графовые преобразования, как правило,
должны удовлетворять набору более специфических аксиом. Например, преобразование AddAccessor не должно привести к случайной перегрузке метода, т. е. в рамках этого преобразования
существует опасность ввести новые методы, которые перегрузили бы методы, определенные в подклассах.
Подобные аксиомы могут быть описаны с помощью постусловий перезаписи графов. Из соображений эффективности лучше
эти постусловия преобразовать в соответствующие предусловия.
Это приведет к возможности до применения преобразования судить о его целесообразности. Формально, предусловия перезаписи графов могут определяться с помощью негативных условий
выполнения [152–154].
На рис. 78 представлены негативные предусловия, необходимые для преобразования AddAccessor в рамках удовлетворения
Bo
Ex
?*
ac
Va
Bo
v1
var
Va
var
?*
v1
ac
Ex
Ex
dy
v5
v4
Bo
ex
accessor
v3
Si
li
accessor
Рис. 77. Сохранение свойства модификации для AddAccessor
v1
Va
me
var
Cl
ge*
Cl
ge*
Cl
me
Bo
accessor
li
Si
accessor
v1
Va
var
me
Cl
me
Bo
accessor
li
Si
accessor
Рис. 78. Отрицательные предусловия для AddAccessor
201
аксиоме. Условия описывают, что ни предшественники, ни последователи в рамках классовой иерархии класса, содержащего
переменную var, не должны иметь методов с сигнатурой accessor.
Требование аксиомы (1) удовлетворяется, поскольку AddAccessor
не вводит новых переменных и не изменяет классовой иерархии.
Требование аксиомы (2) удовлетворяется благодаря предусловию
на рис. 78, в случае, если ge* – пустое слово. Требование аксиомы
(3) удовлетворяется, поскольку AddAccessor только лишь вводит
методы доступа к переменной, определенной в самом классе.
4.1.5. Преобразования диаграмм классов UML
В главе 1 были перечислены шаги по настройке описательных
элементов модели:
1) идентификация типов вершин и ребер;
2) определение частичного порядка вершин и ребер;
3) построение типового графа;
4) определение семейства некорректных подграфов;
5) описание аксиом для вершин и ребер;
6) создание семейства комплексных преобразований.
Воспользовавшись результатами этих действий, опишем преобразования диаграмм классов UML.
Описание элементарных преобразований
В табл. 25 приведен перечень элементарных преобразований
UML-диаграмм. Эта совокупность образует базис преобразований. В целях оптимизации процесса преобразований существует
возможность пополнения списка элементарных преобразований,
например, можно ввести RenameClass за счет использования
RenameV или RetypeAttribute с использованием RetypeV. Основанием для такого расширения должен послужить анализ целей
создания множества преобразований. Каждое из базисных элементарных преобразований UML-диаграмм классов описывается
с помощью совокупности соответствующих парадигмонезависимых преобразований, пред- и постусловий.
Описание составных преобразований
На основе элементарных преобразований существует возможность описать комплексное, составное преобразование. Выделение комплексного преобразования в отдельный класс мотивируется частотой применения и концептуальной значимостью этого преобразования. В соответствии с задачами преобразований,
202
203
InsertV(C,class)
DropV(C,class)
(a,attribute)∈VG:
InsertE(C,a,o,ownership)
(a,attribute)∉ VG:
InsertV(a,attribute)
°InsertE(C,a,o,ownership)
DropE(C,a,o,ownership)
InsertE(a,C,D,association):
(ms(a)=mC)∧ (mt(a)=mD)
DropE(a,C,association)
DropClass(C)
AddAttribute(a,C)
DropAttribute(a,C)
AddAssociation
(a,C,D,mC, mD)
DropAssociation(a,C)
Графовая продукция
AddClass(C)
Тип преобразования
(C,a,o,ownership)∉
OUTG(C)
(C,a,o,ownership)∈
OUTG(C)
(C,class)∉VG
(C,class)∈VG
Постусловие
Таблица 25
(a,ownership)∈ OUTG(C)
(a,ownership)∉ OUTG(C)
(C∈VG)∧(D∈VG)∧
((a,association)∈
((a,association)∉
OUTG(C)) ∧
OUTG(C)) ∧
((a,association)∈ ING(D))
((a,association)∉ ING(D))
(C,a,o,ownership)∈
OUTG(C,class)
((C,class)∈VG)∧
((C,a,o,ownership)∉
OUTG(C,class))
((C,class)∈VG)∧
(AG(C,class)=∅)
(C,class)∉VG
Предусловие
Элементарные преобразования UML-диаграммы классов
204
((a,generalization)∈
OUTG(C))∧
((a,generalization)
∈ING(D))
DropGeneralization(C,D) DropE(a,C,D,generalization)
((a,generalization)∉
OUTG(C)) ∧
((a,generalization)∉
ING(D))
((a,generalization)∈
OUTG(C))∧
((a,generalization)∈
ING(D))
(C∈VG)∧(D∈VG) ∧
((a,generalization)∉ EG:
((s(a,generalization)=C)∧
(t(a,generalization)=D))∨
((s(a,generalization)=D)∧
(t(a,generalization)=C)))
AddGeneralization(C,D) InsertE(a,C,D,generalization)
(C,o,p,ownership)∈
OUTG(C)
Постусловие
(C,o,p,ownership)∉
OUTG(C)
DropE(C,o,p,ownership)
DropOperation(o,C)
((C,class)∈VG)∧
((C,o,p,ownership)∉
OUTG(C,class))
Предусловие
(C,o,p,ownership)∈
OUTG(C,class)
(o,operation)∈VG:
InsertE(C,o,p,ownership)
(o,operation)∉ VG:
InsertV(o,operation)
°InsertE(C,o,p,ownership)
Графовая продукция
AddOperation(o,C)
Тип преобразования
Окончание табл. 25
может быть сформирован тот или иной каталог комплексных
преобразований. Некоторые виды комплексных преобразований
представлены ниже.
1. Построение общего предка для набора классов:
1) обозначение BuildCommonParent(C,C1,…,Cn);
2) совокупность графовых продукций:
выполнить
AddClass(C),
AddGeneralization(C1, C);
…
AddGeneralization(Cn , C);
для
" (a, attribute) Î ∩ t((a, ownership) Î
∪
OUTG (Ci ))
∪
OUTG (Ci ))
iÎ{1..n}
выполнить AddAttribute(a,C);
для
" (o, operation) Î ∩ t((o, ownership) Î
iÎ{1..n}
выполнить AddOperation(o,C);
для
" (a, Ck , o, ownership) Î (∩ (o, ownership) Î
∪
iÎ{1..n}
OUTG (Ci )), k = {1..n}
выполнить DropE(a,Ck);
3) предусловие
{(C1, class)…(Cn , class)} Í VG Ù C Ï VG Ù {e : e Î
∪
iÎ{1…n}
OUTG (Ci ) Ù
Ùet(e) = generalization} = Æ;
4) предусловие
C Î VG Ù
æ
ö÷
ç
Ùçç "e : e Î ∪ OUTG (Ci )÷÷÷ Ù
çç
÷÷ø
è
iÎ{1…n}
Ùet(e) = generalization Þ t(e) = C.
205
2. Удаление общего предка для набора классов:
1) обозначение DestroyParentClass(C);
2) совокупность графовых продукций:
для
"Ci : (Ci , C, gi , generalization) Î ING (C);
"ak : (a, C, ak , ownership) Î OUTG (C)
выполнить AddAttribute(ak,Ci);
для
"ol : (a, C, ll , ownership) Î OUTG (C)
выполнить AddOperation(ol,Ci);
для
" (Ci , C, generalization) Î ING (C)
выполнить DropGeneralization(Ci,C);
выполнить DropClass(C);
3) предусловие
(C, class) Î VG Ù
Ù
∪
e:et(e)=generalizationÙ
eÎING (C)
e = AG (C);
4) постусловие
(C, class) Ï VG .
3. Вывод набора атрибутов в отдельный класс:
1) обозначение BuildAggregateClass(C,D,v1,…,vn);
2) совокупность графовых продукций:
AddClass(D);
AddAttribute(vi , D), i Î {1..n};
DropAttribute(vi , C), i Î {1..n};
AddAssociation(a, C, D,1,1);
3) предусловие
(D, class) Ï VG ;
4) постусловие
(a, C, D, association,1,1) Ï OUTG (C).
206
4. Инкапсуляция атрибутов в агрегирующий класс:
1) обозначение DestroyAggregateClass(C,D);
2) совокупность графовых продукций:
для
"vi : (a, D, ai , ownership) Î OUTG (D)
выполнить AddAttribute(vi,C);
для
"vi : (a, D, ai , ownership) Î OUTG (D)
выполнить DropAttribute(ai,D);
для
(a, C, D, association) Î OUTG (C)
выполнить DropAssociation(a,C,D);
выполнить DropClass(D);
3) предусловие
AG (D) = (a, C, D, association) ∪
∪
vi :vt(vi )=attribute
(vi , D, a, ownership);
4) постусловие
D Ï VG .
Приведенные составные преобразования иллюстрируются на
рис. 79–82.
Некоторые другие типы преобразований можно найти в [133–
136], используя предлагаемый формализм, все они могут быть
смоделированы как составные преобразования.
Представление остальных UML-диаграмм
Помимо диаграмм классов, остальные UML-диаграммы также могут быть представлены с помощью предлагаемого формализма. Для представления некоторой диаграммы необходимо
выполнить следующие шаги:
1) определить части UML-метамодели, описывающие требуемую для представления диаграмму;
2) отобразить соответствующие требуемой диаграмме метаклассы UML-метамодели на вершины и ребра типового графа;
3) сформулировать для типового графа ограничения на основе
ограничений на метамодель диаграммы, описанных на OCL;
4) определить частичный порядок типов вершин и ребер, основываясь на отношениях обобщения между соответствующими
элементами UML-метамодели;
207
208
(FOEFS
0DDVQBUJPO
1BTTQPSU
HFOEFS
PDDVQBUJPO
QBTTQPSU
(FOEFS
3BOL
$BUFHPSZ
HFOEFS
SBOL
DBUFHPSZ
.JMJUBSZ$BSE
$BUFHPSZ
3BOL
(FOEFS
%BUF
4USJOH
4USJOH
*E
Рис. 79. Исходное состояние диаграммы классов для преобразования
BuildCommonParent(Individual,Civilian,Military) и целевое для DestroyParentClass(Civilian)
TFU.JMJUBSZ$BSE.JMJUBSZ$BSENJMJUBSZ$BSE
HFU.JMJUBSZ$BSE
TFU$BUFHPSZ$BUFHPSZDBUFHPSZ
HFU$BUFHPSZ
TFU3BOL3BOLSBOL
TFU1BTTQPSU1BTTQPSUQBTTQPSU
HFU3BOL
1BTTQPSU
HFU1BTTQPSU
TFU(FOEFS(FOEFSHFOEFS
TFU0DDVQBUJPO0DDVQBUJPOPDDVQBUJPO
HFU(FOEFS
0DDVQBUJPO
HFU0DDVQBUJPO
TFU#JSUIEBUF%BUFCJSUI%BUF
TFU(FOEFS(FOEFSHFOEFS
HFU#JSUI%BUF
(FOEFS
HFU(FOEFS
TFU-BTU/BNF4USJOHMBTU/BNF
TFU#JSUI%BUF%BUFCJSUI%BUF
HFU-BTU/BNF
HFU#JSUI%BUF
%BUF
TFU-BTU/BNF4USJOHMBTU/BNF
TFU'JSTU/BNF4USJOHGJSTU/BNF
HFU-BTU/BNF
HFU*E
HFU'JSTU/BNF
4USJOH
%BUF
CJSUI%BUF
NJMJUBSZ$BSE .JMJUBSZ$BSE
4USJOH
4USJOH
*E
GJSTU/BNF
MBTU/BNF
JE
.JMJUBSZ
TFU'JSTU/BNF4USJOHGJSTU/BNF
4USJOH
%BUF
CJSUI%BUF
*E
4USJOH
MBTU/BNF
HFU'JSTU/BNF
4USJOH
GJSTU/BNF
HFU*E
*E
JE
$JWJMJBO
209
HFU3BOL
3BOL
TFU3BOL3BOLSBOL
HFU$BUFHPSZ
$BUFHPSZ
TFU$BUFHPSZ$BUFHPSZDBUFHPSZ
HFU.JMJUBSZ$BSE
.JMJUBSZ$BSE
TFU.JMJUBSZ$BSE.JMJUBSZ$BSENJMJUBSZ$BSE
.JMJUBSZ
SBOL
3BOL
DBUFHPSZ
$BUFHPSZ
NJMJUBSZ$BSE .JMJUBSZ$BSE
Рис. 80. Исходное состояние диаграммы классов для преобразования
DestroyParentClass(Civilian) и целевое для BuildCommonParent(Individual,Civilian,Military)
HFU0DDVQBUJPO
0DDVQBUJPO
TFU0DDVQBUJPO0DDVQBUJPOPDDVQBUJPO
HFU1BTTQPSU
1BTTQPSU
TFU1BTTQPSU1BTTQPSUQBTTQPSU
$JWJMJBO
PDDVQBUJPO 0DDVQBUJPO
QBTTQPSU
1BTTQPSU
*OEJWJEVBM
*E
4USJOH
4USJOH
%BUF
(FOEFS
HFU*E
*E
HFU'JSUTU/BNF
4USJOH
TFU'JSTU/BNF4USJOHGJSTU/BNF
HFU-BTU/BNF
4USJOH
TFU-BTU/BNF4USJOHMBTU/BNF
HFU#JSUI%BUF
%BUF
TFU#JSUI%BUF%BUFCJSUI%BUF
HFU(FOEFS
(FOEFS
TFU(FOEFS(FOEFSHFOEFS
JE
GJSTU/BNF
MBTU/BNF
CJSUI%BUF
HFOEFS
1FSTPO
JE
GJSTU/BNF
MBTU/BNF
CJSUI%BUF
HFOEFS
QBTTQPSU/VNCFS
QBTTQPSU4FSJF
HJWFO#Z
UBLFO%BUF
*E
4USJOH
4USJOH
%BUF
(FOEFS
4USJOH
4USJOH
4USJOH
%BUF
Рис. 81. Исходное состояние диаграммы классов для преобразования
BuildAggregateClass(Person,Passport,pasportNumber,pasportSerie,given
By,takenDate) и целевое для DestroyAggregate(Person,Passport)
1FSTPO
JE
*E
GJSTU/BNF 4USJOH
MBTU/BNF 4USJOH
CJSUI%BUF %BUF
HFOEFS
(FOEFS
1BTTQPSU
QBTTQPSU/VNCFS4USJOH
QBTTQPSU4FSJF
4USJOH
HJWFO#Z
4USJOH
UBLFO%BUF
%BUF
Рис. 82. Исходное состояние диаграммы классов для преобразования
DestroyAggregate(Person,Passport) и целевое для BuildAggregate
Class(Person,Passport,pasportNumber,pasportSerie,givenBy,takenDate)
5) определить типы преобразований, специфичных для представляемой диаграммы в рамках типичных для нее процессов
создания и модификации.
4.2. Алгоритм преобразований программных средств
Основной задачей алгоритма преобразований является выбор
последовательности преобразований на основе анализа соотношений эталонного (дефектного) подпространств и расположения
точки в метрическом пространстве, характеризующей оценку
качества ПС (или ее сущностей).
В качестве основы алгоритма преобразований выступают алгоритмы поиска оптимальной композиции операторов Atb:Mb→Mb
и Atd:Md→Md модели измерений и алгоритма нормализации составных преобразований. На основе первого алгоритма будет
сформирована последовательность преобразований, на основе
210
¨ÉÁžƾÆÁ¾ÈÇÊľ½Ç»¹Ë¾ÄÕÆÇÊËÁ
ÈɾǺɹÀÇ»¹ÆÁÂ
§Ï¾ÆùùоÊË»¹
<½¹>
£¹Ð¾Ê˻ǨªÌ½Ç»Ä¾Ë»ÇÉÁ˾ÄÕÆǾ
<ƾË>
¨ÇÁÊÃÊÌÒÆÇÊ˾Â
½¾Í¾ÃËÆÔÎÈǽÈÉÇÊËɹÆÊË»
¦ÇÉŹÄÁÀ¹ÏÁØÈÇÊľ½Ç»¹Ë¾ÄÕÆÇÊËÁ
ÈɾǺɹÀÇ»¹ÆÁÂ
¨ÇÁÊÃÇÈËÁŹÄÕÆÇÂÈÇÊľ½Ç»¹Ë¾ÄÕÆÇÊËÁ
ÇȾɹËÇÉÇ»ÈɾǺɹÀÇ»¹ÆÁÂ
Рис. 83. Схема этапов алгоритма преобразований ПС
второго эта последовательность будет нормализована. На рис. 83
представлена схема алгоритма преобразований ПС с использованием диаграммы действий UML.
Рассмотрим процессы, составляющие алгоритм преобразований ПС.
4.2.1. Поиск сущностей дефектных подпространств
Поиск сущностей дефектных подпространств осуществляется
на основе заданных пороговых значений метрик. Те сущности
программы (например, классы, методы и т. п.), для которых значение определенной метрики не принадлежит пороговому интервалу, классифицируются как дефектные и являются кандидатами на применение преобразований.
4.2.2. Поиск оптимальной последовательности операторов
На каждом метрическом пространстве, соответствующем
базовой метрике, определен базовый оператор преобразований Atb:Mb→Mb, соответствующий элементарным преобразованиям графовых моделей ПС, определяемым базисом
Pb={InsertV,InsertE, DropV,DropE}.
На каждом метрическом пространстве, соответствующем производной метрике, может быть определено m(m≥1) производных
операторов преобразований Atd:Md→Md, которые соответствуют составным преобразованиям графовых моделей ПС, определяемых композициями условных продукций вида pC=p1°p2°…
°pn:G0→Gn.
211
В случае необходимости изменить модель ПС относительно
базовой метрики выбор оператора оказывается однозначным.
При необходимости изменения модели ПС относительно производной метрики нужно осуществить многокритериальный выбор
нужного производного оператора из m-существующих.
Каждый из производных операторов может характеризоваться побочным эффектом, состоящем в том, что, помимо изменения
значения целевой метрики, оператор может изменить значения
других метрик, ухудшив качество ПС. Алгоритм поиска оптимальной последовательности преобразований позволяет учесть
влияние побочных эффектов на качество ПС и до выполнения
преобразований выбрать наиболее оптимальную в смысле улучшения качества последовательность преобразований. Идея алгоритма состоит в генерации всех возможных последовательностей
преобразований, согласованных в смысле соблюдения пост- и
предусловий (рис. 84), оценке результата их применений и выборе последовательности, применение которой влечет наилучшее
изменение качества ПС. Под наилучшим изменением качества
понимается максимальная близость точки в многомерном метрическом пространстве, характеризующей текущее состояние
ПС к точке, соответствующей эталонному состоянию. Проблема
точной достижимости эталонной точки трудно разрешается с помощью формальных методов. В «идеальном» смысле за счет применения базовых и производных операторов можно достичь любой точки многомерного метрического пространства. Проблема
«реальной» достижимости возникает благодаря ограничениям
на области действия базовых и производных операторов метрических пространств, которые являются следствием необходимости учета следующих факторов:
– семантики языка – например, нельзя создать класс без атрибутов, методов и наследования (С++), нельзя создать класс без
наследования (Java) и т. п.;
– семантики программы – операторы преобразований в метрических пространствах должны быть безопасны по отношению
к функциональным свойствам программы.
Исходя из трудности формализации семантик языка и реальной программы, в основу алгоритма генерации последовательности преобразований положен прямой перебор всех возможных
вариантов преобразований, с последующим оцениванием каждого варианта и выбором наилучшего из них.
212
213
UE
BD " -
UE
BD " -
UE
BD " -
UE
BD " -
UE
UE
UE
UE
"
"
BD " 3
BD " 3
BD " 3
UE
"
UE
BD " 3
UE
E
UE
"
.
UE
UE
UE
"
BD " 3
BD " 3
UE
"
UE
BD " 3
UE
BD " 3
UE
BD " 3
UE
BD " 3
UE
"
UE
"
UE
"
UE
"
E
UEO
BD " -
UEO
BD " -
Рис. 84. Схема образования последовательностей
операторов преобразований
¨ÇÊľ½Ç»¹Ë¾ÄÕÆÇÊËÁÇȾɹËÇÉÇ»ÈɾǺɹÀÇ»¹ÆÁÂ
BD " -
UE
BD " -
UE
BD " -
UE
UE
BD " -
UE
BD " -
UE
BD " -
.
¾Í¾ÃËÆǾÈǽÈÉÇÊËɹÆÊË»ÇOžÉÆǼÇÈÉÇÊËɹÆÊË»¹Åǽ¾ÄÁžËÉÁÃ
ªÇÊ˹»ÄØ×ÒÁ¾½¾Í¾ÃËÆǼÇÈǽÈÉÇÊËɹÆÊË»¹
EO
UEO
"
UEO
"
.
UEO
BD " 3
UEO
BD " 3
Алгоритм поиска оптимальной последовательности
преобразований
Данные алгоритма:
i,j,h,l∈N – индексы, заданные на множествах метрических
пространств и операторов;
n – количество измерений в пространстве метрик;
Ai(j,h,l) – i(j,h,l)-й производный оператор, определенный на
конкретном метрическом пространстве;
R – множество кандидатов – потенциально оптимальных операторов преобразований;
U – вспомогательное множество кандидатов – потенциально
оптимальных операторов преобразований.
Функция produceAChain(R,i): – рекурсивная функция, порождающая производные операторы:
шаг 1: l=1;
шаг 2: для ∀j:Aj∈R выполнить:
шаг 2.2: для "h : ac( Aj )R = ac( Ahtdi+1 )L выполнить:
шаг 2.2.1: Al = Aj  Ahtdi+1,
шаг 2.2.2: U=U∪Ai,
шаг 2.2.3: l=l+1;
шаг 3: i=i+1;
шаг 4: если i<n, то выполнить produceAChain(U,i).
Основной алгоритм:
m
шаг 1: положить i = 1, R = ∪ Altdi , где m – количество оператоl=1
ров на i-м метрическом пространстве;
шаг 2: выполнить produceAChain(R,i);
шаг 3: оценить значения производной метрики, соответствующей понятию качества ПС m Î M1d0 для каждого производного
оператора Ai∈R и выбрать тот оператор Ai, для которого значение
метрики качества является наиболее близким к установленному
эталонному интервалу.
4.2.3. Нормализация составных преобразований
Для оптимизации набора составных преобразований, соответствующих найденному оптимальному производному оператору,
вводится алгоритм нормализации. Основным видом оптимизации служит удаление взаимопоглощающих преобразований (например, InsertV(v1,t1)°DropV(v1,t1)). Зачастую взаимопоглощающие преобразования не являются смежными в составном, по214
этому стоит задача сделать соседними все взаимопоглощающие
преобразования. Изменение порядка преобразований возможно
лишь в случае их последовательной независимости.
4.2.4. Алгоритм нормализации составных преобразований
С использованием определений минимальности преобразований существует возможность приведения некоторого составного
преобразования к минимальной форме. Итоговое минимальное
составное преобразование будет состоять из последовательности:
1) композиции добавлений вершин pCIV;
2) композиции изменений меток вершин pCLV;
3) композиции изменений типов вершин pCTV;
4) композиции добавлений ребер pCIE;
5) композиции изменений меток ребер pCLE;
6) композиции изменений типов ребер pCTE;
7) композиции удалений ребер pCDE;
8) композиции удалений вершин pCDV.
Процесс получения такого минимального составного преобразования будет по аналогии с подходом, связанным с изменением
схемы базы данных, называться нормализацией, а итоговое преобразование будет считаться имеющим нормальную форму. Процесс нормализации состоит в абсорбции всевозможных элементарных преобразований и с дальнейшим упорядочением последовательно независимых преобразований в указанном порядке.
В качестве основы процесса нормализации используется алгоритм сортировки методом пузырька. Каждая пара последовательно независимых преобразований может быть или абсорбирована,
или поменяна местами. Повторяя попытки абсорбции и замены,
можно сгруппировать однотипные преобразования в рамках
данного составного. Опишем процесс перестановки и абсорбции
формально. Обозначим t – тип преобразования, ptemp – вспомогательная переменная, typep:pi→Pe – функция, возвращающая тип
конкретного преобразования для хранения параметров элементарного преобразования.
Алгоритм перестановки:
шаг 1: если (typep(pi)=t)∧(typep(pi-1)≠t), шаг 2, иначе шаг 4;
шаг 2: если pi и pi–1 (согласно определению 111) являются последовательно независимыми, то присвоить ptemp=pi, pi = pi–1,
pi–1=ptemp, j=i;
215
шаг 3: иначе заменить pi-1°pi абсорбирующим преобразованием pi¢-1 = pi-1  pi , присвоить j=i, n=n–1;
шаг 4: присвоить i=i+1;
шаг 5: если i≤n, перейти на шаг 1.
Алгоритм нормализации:
для
минимизации
составного
преобразования
p1
pn
pC = G0 ¾¾
®… ¾¾
® Gn необходимо выполнить следующую последовательность действий:
шаг 1: положить t=InsertV, i=2, j=0. Выполнить алгоритм перестановки;
шаг 2: положить t=RelabelV, i=j. Выполнить алгоритм перестановки;
шаг 3: положить t=RetypeV, i=j. Выполнить алгоритм перестановки;
шаг 4: положить t=InsertE, i=j. Выполнить алгоритм перестановки;
шаг 5: положить t=RelabelE, i=j. Выполнить алгоритм перестановки;
шаг 6: положить t=RetypeE, i=j. Выполнить алгоритм перестановки;
шаг 7: положить t=DropE, i=j. Выполнить алгоритм перестановки;
шаг 8: положить t=DropV, i=j. Выполнить алгоритм перестановки;
шаг 9: переиндексировать преобразования от 1 до n;
шаг
10:
найти
все
пары
(pl,pk):(pl=InsertV(v,t))∧
∧(pk=RelabelV(v,t,w)), для каждой пары:
шаг 10.1: переместить InsertV(v,t) в конец pCIV ⊆pC;
шаг 10.2: переместить RelabelV(v,t,w) в начало pCLV ⊆pC;
шаг 10.3: заменить InsertV(v,t)°RelabelV(v,t,w) абсорбирующим преобразованием InsertV(w,t);
шаг
11:
найти
все
пары
(pl,pk):(pl=InsertV(v,t))∧
∧(pk=RetypeV(v,t,q)), для каждой пары:
шаг 11.1: переместить InsertV(v,t) в конец pCIV ⊆pC;
шаг 11.2: переместить RetypeV(v,t,q) в начало pCTV ⊆pC;
шаг 11.3: заменить InsertV(v,t)°RetypeV(v,t,q) абсорбирующим преобразованием InsertV(v,q);
шаг 12: найти все пары (pl,pk):(pl=InsertE(e,v,w,r))∧(pk=RelabelE
(e,v,w,r,f)), для каждой пары:
шаг 12.1: переместить InsertE(e,v,w,r) в конец pCIE ⊆pC;
216
шаг 12.2: переместить RelabelE(e,v,w,r,f) в начало pCLE⊆ 
⊆pC;;
шаг 12.3: заменить InsertE(e,v,w,r)°RelabelE(e,v,w,r,f) абсорбирующим преобразованием InsertE(f,v,w,r);
шаг 13: найти все пары ( pl , pk ) : ( pl = Insert E (e,v,w,r )) Ù
( pk = Retype E (e,v,w,r ,u)), для каждой пары:
шаг 13.1: переместить InsertE(e,v,w,r) в конец pCIE ⊆pC;
шаг 13.2: переместить RetypeE(e,v,w,r,u) в начало pCTE ⊆pC;
шаг 13.3: заменить InsertE(e,v,w,r))°(pk=RetypeE(e,v,w,r,
u)) абсорбирующим преобразованием InsertE(e,v,w,u);
шаг 14: найти все пары (pl,pk):(pl=RelabelE(e,v,w,r,f))∧(pk=DropE
(f,v,w,r)), для каждой пары:
шаг 14.1: переместить RelabelE(e,v,w,r,f) в конец pCLE ⊆pC;
шаг 14.2: переместить DropE(f,v,w,r) в начало pCDE ⊆pC;
шаг 14.3: заменить RelabelE(e,v,w,r,f)°DropE(f,v,w,r) абсорбирующим преобразованием DropE(e,v,w,r);
шаг 15: найти все пары (pl,pk):(pl=RetypeE(e,v,w,r,u))∧(pk=DropE
(e,v,w,u)), для каждой пары:
шаг 15.1: переместить RetypeE(e,v,w,r,u) в начало pCTE ⊆pC;
шаг 15.2: переместить DropE(e,v,w,u) в начало pCDE ⊆pC;
шаг 15.3: заменить RetypeE(e,v,w,r,u)°DropE(e,v,w,u) абсорбирующим преобразованием DropE(e,v,w,r);
шаг 16: найти все пары (pl,pk):(pl=RelabelV(v,t,w))∧(pk=DropV
(w,t)), для каждой пары:
шаг 16.1: переместить RelabelV(v,t,w) в конец pCLV ⊆pC;
шаг 16.2: переместить DropV(w,t) в начало pCDV ⊆pC;
шаг 16.3: заменить RelabelV(v,t,w)°DropV(w,t) абсорбирующим преобразованием DropV(v,t);
шаг 17: найти все пары (pl,pk):(pl=RetypeV(v,t,q))∧(pk=DropV
(v,q)), для каждой пары:
шаг 17.1: переместить RetypeV(v,t,q) в конец pCTV ⊆pC;
шаг 17.2: переместить DropV(v,q) в начало pCDV ⊆pC;
шаг 17.3: заменить RetypeV(v,t,q)°DropV(v,q) абсорбирующим преобразованием DropV(v,t);
шаг 18: найти все пары (pl,pk):(pl=InsertE(e,v,w,r))∧(pk=DropE
(e,v,w,r)), для каждой пары:
шаг 18.1: переместить InsertE(e,v,w,r) в конец pCIE ⊆pC;
шаг 18.2: переместить DropE(e,v,w,r) в начало pCDE ⊆pC;
шаг 18.3: Удалить взаимопоглащающую композицию преобразований InsertE(e,v,w,r)°DropE(e,v,w,r);
217
шаг 19: найти все пары (pl,pk):(pl=InsertV(v,t))∧(pk=DropV(v,
t)), для каждой пары:
шаг 19.1: переместить InsertV(v,t) в конец pCIV ⊆pC;
шаг 19.2: переместить DropV(v,t) в начало pCDV ⊆pC;
шаг 19.3: удалить взаимопоглощающую композицию преобразований InsertV(v,t)°DropV(v,t);
Алгоритм нормализации всегда ведет к получению минимального составного преобразования, однако полученная нормальная
форма не является уникальной. Каждая из нормальных форм содержит одно и то же множество элементарных преобразований,
но последние могут быть по-разному упорядочены.
Лемма 32. Уникальность нормальной формы. Каждая нормальная форма составного преобразования уникальна с точностью до переупорядочения элементарных преобразований, входящих в ее состав.
Доказательство. Допустим, что существует два минимальp1
p2
m
m
ных составных преобразования G ¾¾®
H и G ¾¾®
H. Пока-
1
2
жем, что выполняется "i : pi Î pm
Þ pi Î pm
. Допустим, что: 1)
pi=InsertV(v,t). Очевидно, что pi не может следовать за DropV(v,t),
так как вместе они представляют собой пару взаимопоглощающих преобразований. Также не найдется ни одного DropV(v,tj), в
силу того, что перед pi необходимо было бы предположить нали1
чие RetypeV(v,tj,t), а это, в силу минимальности pm
, не допустимо, все пары InsertV(v,tj), RetypeV(v,tj,t) абсорбированы. В силу
свойства ортогональности элементарных преобразований можно
заключить, что (v,t)∉G и (v,t)∈H. Так как начальный и результи1
2
2
рующий графы pm
и pm
совпадают, то InsertV (v,t) Î pm
. Анало2
2 минимальна и (v,t)∈H, слегично, InsertV (v,tj ) Ï pm
, так как pm
довательно, не содержит никаких RetypeV(v,tj,t); 2) аналогично
1
2
можно показать, что "i : pi Î pm
Þ pi Î pm
для остальных типов
элементарных преобразований.
Необходимо заметить, что в минимальном составном преобразовании порядок следования однотипных преобразований
не является произвольным в силу того, что они в общем случае
последовательно зависимы. Основные преимущества нормализованного составного преобразования состоят в минимальности
числа элементарных преобразований и в упорядоченности однотипных преобразований.
218
Алгоритм генерации нормализованного составного преобразования
Алгоритм генерации нормализованного составного преобразования применяется в случае наличия лишь начального и конечного графов.
Алгоритм генерации. Пусть имеется начальный граф G и конечный граф H. Положим pC=∅, pCIV=∅, pCIE=∅, pCDE=∅, pCDV=∅:
шаг 1: для каждой вершины (v,t):((v,t)∉G)∧((v,t)∈H) выполнить pCIV = pCIV°InsertV(v,t);
шаг 2: для каждого ребра (e,v,w,t):((e,v,w,t)∉G)∧((e,v,w,t)∈H)
выполнить pCIV=pCIE°InsertE(e,v,w,t);
шаг 3: для каждого ребра (e,v,w,t):((e,v,w,t)∈G)∧((e,v,w,t)∉H)
выполнить pCDV=pCDE°DropE(e,v,w,t);
шаг 4: для каждой вершины (v,t):((v,t)∈G)∧((v,t)∉H) выполнить pCDV = pCDV°DropV(v,t);
шаг 5: положить pC=pCIV°pCIE°pCDE°pCDV.
Лемма 33. Алгоритм генерации. Составное преобразование,
получаемое с помощью алгоритма генерации, является допустимым и минимальным.
Доказательство.
1. Допустимость:
а) для каждого pi=InsertV(v,t) предусловие ((v,t)∉Li)⊆ac(pi)L
выполняется, так как pCIV содержит максимум одно InsertV(v,t)
для каждого (v,t);
б) для каждого pi=InsertE(e,v,w,t) предусловие ((e,v,w,t)∉Li)∧ 
∧((v,t)∈Li)∧((w,t)∈Li)⊆ac(pi)L выполняется, так как pCLV содержит максимум одно InsertE(e,v,w,t) для каждого (e,v,w,t),
((v,t)∈Li)∧((w,t)∈Li), так как эти вершины или существовали в G,
или создались при формировании pCIV;
в) аналогично, для pi=DropE(e,v,w,t) и pi=DropV(v,t).
2. Минимальность:
а) взаимопоглощающие преобразования недопустимы в pC, в
силу конструкции алгоритма, например, InsertV(v,t)°DropV(v,t)
отсутствует, так как для InsertV(v,t) необходимо (v,t)∉H, а для
DropV(v,t) – (v,t)∈H, аналогичные взаимоисключающие условия
справедливы для остальных типов взаимопоглощений;
б) абсорбирующие преобразования отсутствуют в pC, в силу использования в алгоритме только базисных элементарных преобразований InsertV(v,t), InsertE(e,v,w,t), DropV(v,t), DropE(e,v,w,t).
Подобные алгоритмы генерации можно найти в работах [107,
108]. Оба подхода ограничены предметной областью, связанной с
объектно-ориентированным программным обеспечением.
219
Глава 5. Управление качеством
программных средств
Система управления качеством ПС включает компоненты, в
основу функционирования которых положены модели, описанные в предыдущих главах. Цель системы управления качеством
состоит в обеспечении оценивания и улучшения качества ПС в
соответствии с заданной моделью качества.
5.1. Структура системы управления
качеством программных средств
Объектом управления системы является модель ПС, модель
качества формирует внешнюю среду. В общем виде компоненты
системы управления качеством и их взаимодействие показаны
на рис. 85.
5.2. Описание элементов системы управления
качеством программных средств
На рис. 86 представлен контур системы управления качеством
ПС. Рассмотрим задачи его элементов подробнее.
1. Задачи подсистемы формирования модели измерений:
1) автоматическая генерация (с помощью функтора) модели измерений на основе модели качества, формируемой экспертами или соответствующей определенному стандарту качества;
2) предоставление эксперту механизма для определения состава базовых метрик;
3) предоставление эксперту инструментария для определения
функциональных зависимостей между метриками;
4) предоставление эксперту возможностей по определению
эталонных значений метрик;
5) анализ репозитория проектов для автоматического определения эталонных значений метрик.
2. Задачи подсистемы идентификации состояний ПС:
1) определение значений метрик на основе модели измерений
и модели ПС;
2) определение состояния ПС и его компонент на основе значений метрик с использованием методов классификации и теории
принятия решений.
3. Задачи подсистемы формирования преобразований:
220
221
£Ç½
£Ç½
¥Ç½¾ÄÕ
ùоÊË»¹
¥Ç½¾ÄÕ
ÁÀžɾ
ÆÁÂ
¨É¾ÇºÉ¹ÀÇ
»¹ÆƹØ
Åǽ¾ÄÕ¨ª
£Ä¹ÊÊÔ
ùоÊË»¾ÆÆǼÇ
ÊÇÊËÇØÆÁبª
ǺÌй×Ò¹Ø
»ÔºÇÉù
£Ä¹ÊÊÁÍÁùÏÁØ
ùоÊË»¾ÆÆǼÇ
ÊÇÊËÇØÆÁبª
¥Ç½¾ÄÕ
¨ª
¨Ç½ÊÁÊ˾ŹÁ½¾ÆËÁÍÁùÏÁÁ
ÊÇÊËÇØÆÁ¨ª
¥Ç½¾ÄÕ
¨ª
¥Ç½¾ÄÕ¨ª
ªÇÊËÇØÆÁ¾
¨ª
¥Ç½¾ÄÕ
¨ª
›Á½Ô
ÈɾǺɹ
ÀÇ»¹ÆÁÂ
ÊÇÊËÇØÆÁÂ
ÊÌÒÆÇÊ˾Â
Åǽ¾ÄÁ¨ª
›Ôº
ɹÆÆÔÂ
ƹºÇÉ
ÈɾǺɹÀÇ
»¹ÆÁÂ
Åǽ¾ÄÁ¨ª
¨Ç½ÊÁÊ˾ŹÍÇÉÅÁÉÇ»¹ÆÁØ
ÈɾǺɹÀÇ»¹ÆÁÂ
¨É¾ÇºÉ¹ÀÇ»¹ÆÁØ
¨É¾ÇºÉ¹ÀÇ»¹Æ
ƹØÅǽ¾ÄÕ
¨ª
¨Ç½ÊÁÊ˾Źɾ¹ÄÁÀ¹ÏÁÁÈɾǺɹÀÇ»¹ÆÁÂ
Рис. 85. Общая структура системы управления качеством ПС
¥Ç½¾ÄÕ
ÁÀžɾÆÁÂ
¡ÊÎǽÆÔÂ
Ãǽ
¨Ç½ÊÁÊ˾ŹÅǽ¾ÄÁÉÇ»¹ÆÁبª
¨Ç½ÊÁÊ˾ŹÅǽ¾ÄÁÉÇ»¹ÆÁØ
ùоÊË»¹
¡ÊÎǽÆÔÂ
Ãǽ
¨ÉǼɹÅÅÆǾ
Êɾ½ÊË»Ç
¥Ç½¾ÄÕ¨ª
¨Ç½ÊÁÊ˾Ź
¨Ç½ÊÁÊ˾Ź
Á½¾ÆËÁÍÁùÏÁÁ ¥Ç½¾ÄÕžËÉÁà ÍÇÉÅÁÉÇ»¹ÆÁØ
Åǽ¾ÄÁžËÉÁÃ
ÊÇÊËÇØÆÁبª
ªÇÊËÇØÆÁ¾¨ª
›ÔÈÇÄƾÆÁ¾
ÈɾǺɹÀÇ
»¹ÆÁÂ
¥Ç½¾ÄÕ¨ª
¨Ç½ÊÁÊ˾Ź
¨Ç½ÊÁÊ˾Ź
¨É¾ÇºÉ¹ÀÇ»¹ÆÁØ ÍÇÉÅÁÉÇ»¹ÆÁØ
ɾ¹ÄÁÀ¹ÏÁÁ
ÈɾǺɹÀÇ»¹ÆÁÂ
ÈɾǺɹÀÇ»¹ÆÁÂ
Рис. 86. Контур системы управления качеством ПС
1) определение оптимального набора преобразований на основе состояния ПС с использованием методов классификации и
теории принятия решений.
4. Задачи подсистемы реализации преобразований:
1) выполнение преобразований над графовой моделью ПС.
5.3. Применение методов классификации
и кластерного анализа
В системе управления качеством программных средств в подсистемах идентификации состояния и формирования преобразований целесообразно применить алгоритмы классификации
и принятия решений. Идентификация состояния программного
средства представляет собой принятие решения о принадлежности этого состояния к определенной классификационной категории. Формирование преобразований представляет собой принятие решения, состоящее в выборе набора преобразований программного средства, оптимального по определенному критерию.
В подсистемах идентификации и формирования преобразований классы используются как для идентификации текущего состояния ПС, так и для формирования преобразований с учетом
состояния ПС после реализации этих преобразований.
В качестве требований к методам классификации, которые
могли бы использоваться в системе управления качеством, целесообразно сформулировать следующие:
222
1) устойчивость, т. е. состоятельность результатов работы алгоритма;
2) слабая зависимость времени решения задач от размерности
метрического пространства;
3) возможность решения обратных задач классификации, что
необходимо для подсистемы формирования последовательности
преобразований;
4) адаптивность, под которой понимается подстройка алгоритмов управления в соответствии с изменением модели качества.
5.3.1. Сравнительный анализ методов классификации
Методы классификации делятся на три вида – дискриминантный анализ, кластер-анализ, задачи группировки.
Задача дискриминантного анализа состоит в нахождении правила отнесения наблюдаемого объекта к одному из ранее описанных классов. При этом объекты описывают в математической
модели с помощью векторов, координаты которых – результаты
наблюдения ряда признаков у каждого объекта. Классы описывают либо непосредственно в математических терминах, либо с
помощью обучающих выборок. Обучающая выборка – это выборка, для каждого элемента которой указано, к какому классу он
относится. В отличие от регрессионного, дискриминантный анализ позволяет предсказывать значение качественных, а не количественных показателей.
Кластерный анализ применяют, когда по статистическим данным необходимо разделить элементы выборки на группы. Причем два элемента из одной и той же группы должны быть «близкими» по совокупности значений измеренных у них признаков,
а два элемента из разных групп должны быть «далекими» в том
же смысле. В отличие от дискриминантного анализа, в кластеранализе классы не заданы, а формируются в процессе обработки
статистических данных.
Задачи группировки решают тогда, когда классы заранее не
заданы и не обязаны быть «далекими» друг от друга.
В литературных источниках, наряду с термином «классификация», в близких смыслах используются термины «группировка», «распознавание образов», «диагностика», «дискриминация», «сортировка», «типология», «систематика», «районирование», «сегментирование» и др. Терминологический разнобой
связан, прежде всего, с традициями научных школ, к которым
223
относятся авторы публикаций, а также с внутренним делением
самой теории классификации.
В научных исследованиях по современной теории классификации можно выделить два относительно самостоятельных
направления. Одно из них опирается на опыт таких наук, как
биология, география, геология, и таких прикладных областей, как ведение классификаторов продукции и библиотечное
дело. Типичные объекты рассмотрения – классификация химических элементов (таблица Д. И. Менделеева), биологическая систематика, универсальная десятичная классификация
публикаций (УДК), классификатор товаров на основе штрихкодов.
Другое направление опирается на опыт технических исследований, экономики, маркетинговых исследований, социологии,
медицины. Типичные задачи – техническая и медицинская диагностика, а также, например, разбиение на группы отраслей промышленности, тесно связанных между собой, выделение групп
однородной продукции. Обычно используются такие термины,
как «распознавание образов», «кластер-анализ» или «дискриминантный анализ». Это направление обычно опирается на математические модели.
В дискриминантном анализе классы предполагаются заданными – плотностями вероятностей или обучающими выборками.
Задача состоит в том, чтобы вновь поступающий объект отнести в
один из этих классов. У понятия «дискриминация» имеется много синонимов: «диагностика», «распознавание образов с учителем», «автоматическая классификация с учителем», «статистическая классификация» и т. д.
При кластеризации и группировке целью является выявление и выделение классов. Синонимы: «построение классификации», «распознавание образов без учителя», «автоматическая
классификация без учителя», «типология», «таксономия» и др.
При этом задача кластер-анализа состоит в выяснении по эмпирическим данным, насколько элементы «группируются» или
распадаются на изолированные «скопления», «кластеры» (от
англ. cluster – гроздь, скопление). Иными словами, задача – выявление естественного разбиения на классы, свободного от субъективизма исследователя, а цель – выделение групп однородных
объектов, сходных между собой, при резком отличии этих групп
друг от друга.
224
При группировке, наоборот, желательно разбить элементы на
группы независимо от того, естественны границы разбиения или
нет. Цель по-прежнему состоит в выявлении групп однородных
объектов, сходных между собой (как в кластер-анализе), однако
«соседние» группы могут не иметь резких различий (в отличие от
кластер-анализа). Границы между группами условны, не являются естественными, зависят от субъективизма исследователя.
Задачи кластеризации и группировки принципиально различны, хотя для их решения могут применяться одни и те же алгоритмы. Важная для практической деятельности проблема состоит в том, чтобы понять, разрешима ли задача кластер-анализа
для конкретных данных или возможна только их группировка,
поскольку совокупность объектов достаточно однородна и не разбивается на резко разделяющиеся между собой кластеры.
Авторы (Ю. Л. Барабаш [137], В. И. Васильев [138], А. Л. Горелик, В. А. Скрипкин [139], Р. Дуда, П. Харт [140], Л. Т. Кузин
[141], Ф. И. Перегудов, Ф. П. Тарасенко [142], Ф. Е. Темников
[143] и др.) дают различную типологию методов классификации.
Одни различают параметрические, непараметрические и эвристические методы, другие выделяют группы методов, исходя из
исторически сложившихся школ и направлений в данной области. Приведем обобщающий набор классов методов классификации:
1) методы, основанные на оценках плотностей распределения
значений метрик (или сходства и различия объектов) [147];
2) методы, основанные на предположениях о классе решающих функций [144];
3) логические методы [148];
4) лингвистические (структурные) методы [105];
5) метод сравнения с прототипом;
6) метод k-ближайших соседей;
7) алгоритмы вычисления оценок (голосования);
8) коллективы решающих правил;
9) алгоритмы, использующие методы искусственного интеллекта (нейронные сети, генетические алгоритмы).
Для выбора алгоритма классификации необходимо оценить
качество его работы. Главным таким показателем является
устойчивость.
Устойчивость – понятие широкое. Поскольку значения признаков всегда измеряются с погрешностями, то «реальное» раз225
биение должно быть устойчиво (т. е. не меняться или меняться
слабо) при малых отклонениях исходных данных. Алгоритмов
классификации существует бесконечно много, и «реальное» разбиение должно быть устойчиво по отношению к переходу к другому алгоритму. Другими словами, если «реальное» разбиение на
классы возможно, то оно находится с помощью любого алгоритма автоматической классификации. Следовательно, критерием
естественности классификации может служить совпадение результатов работы двух достаточно различающихся алгоритмов,
например, «ближайшего соседа» и «дальнего соседа».
Понятие «ошибка классификации» предполагает, что существует не зависимый от алгоритма классификации способ, позволяющий достоверно определить, к какому классу относится
каждый классифицируемый объект. Обычно (но всегда) считается, что этот способ – экспертная оценка. На этой основе может быть сформулирован другой критерий качества алгоритмов
классификации, который можно было бы назвать «степень соответствия экспертным оценкам». Для оптимизации интерпретации экспертных оценок разработан ряд методов, широко представленных в литературе.
Важной представляется задача реализации в системах классификации механизма обобщения описаний объектов, относящихся к одному классу, т. е. механизма формирования компактных обобщенных образов. Такой механизм обобщения позволит
сжать большую по размерности обучающую выборку к заранее
известному по размерности базису классов. Создание механизма
обобщения может быть реализовано путем решения следующих
задач: определение информационного вклада метрик в информационный портрет обобщенного класса, кластерный анализ обобщенных классов, определение семантической нагрузки метрики,
содержательное сравнение обобщенных классов друг с другом и
метрик друг с другом.
Анализировать скопления точек в трехмерном пространстве
трудно. Непосредственное, визуальное восприятие данных более
высокой размерности невозможно. Поэтому вполне естественным
является желание перейти от многомерной выборки или выборки, состоящей из объектов нечисловой природы, к данным небольшой размерности, чтобы «на них можно было посмотреть».
Статистические технологии такого перехода объединяют термином «методы шкалирования». Если исходные данные – многомерные векторы, то говорят о «методах снижения размерности».
226
Задачи снижения размерности имеют в качестве цели сжатие
информации. Цель их решения состоит в определении набора
производных показателей, полученных преобразованием исходных показателей, такого, что число производных показателей
значительно меньше числа исходных, но они содержат, возможно, большую часть информации, имеющейся в исходных статистических данных. Задачи снижения размерности решают с помощью методов многомерного шкалирования, главных компонент, факторного анализа и др.
Кроме стремления к наглядности, есть и другие мотивы для
шкалирования и снижения размерности. Те факторы, от которых интересующая исследователя переменная не зависит, лишь
мешают статистическому анализу. Во-первых, на сбор информации о них расходуются ресурсы. Во-вторых, как можно доказать,
их включение в анализ ухудшает свойства статистических процедур (в частности, увеличивает дисперсию оценок параметров и
характеристик распределений). Поэтому желательно избавиться
от таких факторов. Метод главных компонент является одним из
наиболее часто используемых методов снижения размерности.
Основная его идея состоит в последовательном выявлении направлений, в которых данные имеют наибольший разброс. Метод главных компонент является одним из методов факторного
анализа. Различные алгоритмы факторного анализа объединены
тем, что во всех них происходит переход к новому базису в исходном n-мерном пространстве. Важным является понятие «нагрузка фактора», применяемое для описания роли исходного
фактора (переменной) в формировании определенного вектора
из нового базиса.
Новая идея по сравнению с методом главных компонент состоит в том, что на основе нагрузок происходит разбиение факторов на группы. В одну группу объединяются факторы, имеющие
сходное влияние на элементы нового базиса. Затем из каждой
группы рекомендуется оставить одного представителя. Иногда
вместо выбора представителя расчетным путем формируется новый фактор, являющийся центральным для рассматриваемой
группы. Снижение размерности происходит при переходе к системе факторов, являющихся представителями групп. Остальные факторы отбрасываются.
Описанная процедура может быть осуществлена не только
с помощью факторного анализа. Речь идет о кластер-анализе
227
признаков (факторов, переменных). Для разбиения признаков
на группы можно применять различные алгоритмы кластеранализа. Достаточно ввести расстояние (меру близости, показатель различия) между признаками.
На использовании расстояний (мер близости, показателей
различия) d(X,Y) между объектами (или признаками) Х и Y
основан обширный класс методов многомерного шкалирования.
Основная идея этого класса методов состоит в представлении
каждого объекта точкой геометрического пространства (обычно
размерности 1, 2 или 3), координатами которой служат значения
скрытых (латентных) факторов, описывающих объект. При этом
отношения между объектами заменяются отношениями между
точками – их представителями. Например, данные о сходстве
объектов – расстояниями между точками, данные о превосходстве – взаимным расположением точек.
В табл. 26 приведено сравнение методов классификации.
Таблица 26
Сравнение методов классификации
Методы
классификации
Специфика
Недостатки
Методы, основанные на оценках
плотностей распределения значений метрик (или
сходства и различия
объектов)
Задачи с известным
распределением, как
правило, нормальным, необходимость
доступа к большому
объему статистических данных
Необходимость перебора
всей обучающей выборки
при классификации, высокая чувствительность
к непредставительности
обучающей выборки
Методы, основанные на предположениях о классе решающих функций
Классы должны
быть хорошо разделяемыми, система
метрик – ортонормированной
Должен быть заранее
известен вид решающей
функции. Невозможность учета новых знаний
о корреляциях между
метриками
Логические методы
Задачи небольшой
размерности пространства метрик
При отборе логических
решающих правил
(конъюнкций) необходим полный перебор, что
влечет высокую вычислительную сложность
228
Окончание табл. 26
Методы
классификации
Лингвистические
методы
Метод сравнения
с прототипом
Метод
k-ближайших
соседей
Специфика
Недостатки
–//–
Задача определения грамматики по множеству
высказываний является
трудно формализуемой
–//–
Высокая зависимость результатов классификации
от метрики
Задачи небольшой
размерности по
количеству классов
и метрик
Алгоритмы вычисления оценок
Коллективы решающих правил
Алгоритмы, основанные на использовании методов
искусственного
интеллекта
Высокая зависимость
результатов классификации от метрики. Необходимость полного перебора
обучающей выборки при
классификации
–//–
Зависимость результатов классификации от
метрики. Необходимость
полного перебора обучающей выборки при классификации
–//–
Высокая вычислительная
сложность
Задачи большой раз- Относительно высокая
мерности, нечеткое вычислительная сложразделение классов, ность
плохо формализуемые задачи
Для успешного выбора или формирования метода классификации для системы управления качеством ПС необходимо решить:
– проблему достижения независимости времени классификации от размерности обучающей выборки;
– проблему корректного снижения размерности пространства
метрик без существенной потери содержащейся в них значимой
информации;
– проблему достижения высокой степени соответствия результатов анализа и действительности.
229
Первая проблема возникает при попытке прямого перебора
вариантов во многих методах классификации.
Вторая проблема – при выявлении наиболее существенного и
отбрасывании относительно несущественного в созданных системой классах. Снижение размерности пространства метрик сводится к двум задачам определения ценности метрик для решения
задачи классификации и отбрасывания незначимых метрик.
Появление тех или других метрик обосновывается моделью
измерений, созданной на основе модели качества. После установки эталонных или дефектных интервалов значений, при формировании на их основе классов может быть выявлен перечень метрик, значения которых не влияют (слабо влияют) на результаты
классификации, а также метрики, обладающие слишком высокой дисперсией. Такого рода метрики в общем случае можно не
учитывать. При этом необходимо иметь в виду, что большинство
метрик являются взаимосвязанными и ценность одних метрик
может меняться при отбрасывании других.
Третья проблема возникает при разработке такой математической модели и ее программной реализации, которые бы обеспечили интуитивно понятную содержательную интерпретацию.
Применение только такого рода моделей можно считать корректным, так как, в противном случае, трудно сказать, как можно
применить результаты их работы.
Для реализации задачи классификации в системе управления
качеством ПС целесообразно выбрать адаптивную модель. Здесь
под адаптацией понимается гибкая перестройка механизма принятия решений, поддерживаемого системой, за счет коррекции
семантической нагрузки метрик и информационного содержания классов, направленная на обеспечение их максимального соответствия изменениям модели качества ПС.
Свойство адаптивности выбирается в связи с тем, что системы, созданные с помощью традиционных статических моделей,
в связи с высокой динамичностью предметной области, быстро
устаревают. Качество работы таких приложений постепенно
ухудшается, со временем они перестают давать корректные и
сопоставимые даже друг с другом результаты. Тогда как адаптивные модели порождают приложения, практическая и научная ценность которых непрерывно возрастает, они позволяют
изучать динамику семантики метрик и классов, т. е. динамику
самой предметной области.
230
Основываясь на анализе достоинств и недостатков существующих методов классификации, учитывая специфику задачи
классификации состояний ПС, состоящую в априорно нечетком
разделении классов и плохой формализации задачи, целесообразно в качестве методов классификации системы управления
качеством программных средств использовать средства искусственного интеллекта.
5.3.2. Применение методов кластерного анализа
Помимо методов классификации, в системе управления качеством ПС целесообразно использовать методы кластерного анализа. Кластеры представляют собой такие группы классов, внутри которых эти классы наиболее схожи друг с другом, а между
которыми – наиболее различны. Задача методов кластерного
анализа в составе системы управления качеством состоит в выявлении общности сущностей ПС, объединении сущностей со сходными характеристиками в одно подпространство. В результате
появляется возможность сравнивать распределения эталонных
и анализируемых ПС или упрощать процедуру экспертной оценки, распространяя последние на все сущности подпространства
на основе оценки некоторого их подмножества.
Исходные состояния ПС, объединенные в кластер, характеризуются близостью значений метрик, а также схожими методами
перевода в целевые состояния.
В рамках кластерного анализа целесообразно использовать
репозитории ПС, качественное состояние которых априори известно. Это могут быть как состояния «эталонное ПС» или «дефектное ПС» с известными соответствующими положительными или отрицательными свойствами, так и состояния ПС, отвечающие определенным моделям качества в той или иной мере.
Наличие репозитория ПС, которые обладают известными свойствами «эталонное» и «дефектное», позволяет сформировать три
множества ПС: S+={s+1,s+2,…, s+n} – множество эталонных ПС,
S–={s–1,s–2,…, s–m} – множество дефектных ПС, S={s1,s2,…, sk} –
множество ПС, качество которых неизвестно (где n+m+k – общее
количество ПС в репозитории). На рис. 87 показан пример результатов кластерного анализа, выполненного на основе анализа
значений метрик ПС репозитория и оцениваемых ПС.
На основе результатов кластерного анализа, представленных
на рис. 87, могут быть сделаны следующие выводы:
231
4
#
4
4
4
4
"
4
4
4
4
$
4
4
%
4
Рис. 87. Пример разбиения ПС на кластеры
1) так как ПС s1 попала в кластер с дефектными ПС, то она
также является дефектной;
2) так как ПС s2 попала в кластер с эталонными ПС, то она
также является эталонной;
3) состояние ПС s3, s4, s5 идентифицировать не удалось, что
свидетельствует о слабости используемого алгоритма кластеранализа;
4) в кластер C попали как дефектные, так и эталонные ПС,
что также интерпретируется как недостаток используемого алгоритма.
Результирующие состояния ПС, объединенные в кластер,
слабо различаются по факторам, детерминирующим перевод ПС
в эти состояния. Это означает, что одно и то же преобразование
при одних и тех же предпосылках (исходном состоянии и предыстории объекта управления и среды) могут привести к переводу
ПС в одно из результирующих состояний, относящихся к одному
кластеру. Поэтому кластерный анализ результирующих состояний ПС является инструментом, позволяющим изучать вопросы
устойчивости управления качеством ПС.
При формировании преобразований как суперпозиции факторов часто возникает вопрос о замене одних преобразований
другими, имеющими сходное влияние на перевод ПС из данного
текущего состояния в заданное целевое состояние. Кластерный
232
анализ преобразований позволяет решить эту задачу – при невозможности применить некоторое преобразование его можно заменить другим из того же кластера.
В соответствии с предлагаемым подходом, формируются кластеры для заданного диапазона классов с различными критериями включения качественного состояния ПС в кластер. Эти
критерии могут быть сформированы автоматически, на основе
репозитория ПС, качество которых априори известно, либо заданы экспертами.
5.4. Алгоритм функционирования системы управления
качеством программных средств
Система классификации входит в состав как подсистемы
идентификации состояния ПС, так и подсистемы формирования
преобразований ПС.
В подсистеме идентификации система классификации применяется для того, чтобы классифицировать состояние качества
ПС, т. е. дать ему обобщающую оценку, не сводящуюся к совокупности значений выходных параметров. Таким образом, в подсистеме идентификации основным является режим классификации.
В подсистеме формирования преобразований по заданным целевым состояниям определяется, какие преобразования могут
перевести ПС, находящееся в данном качественном состоянии,
в это целевое.
Эта задача относится к обратным задачам декодирования и
для системы классификации является стандартной. Она реализуются в режиме анализа, т. е. путем вывода класса с фильтрацией по уровню метрик. После формирования преобразований с помощью подсистемы классификации может быть спрогнозирован
результат их применения.
В подсистеме формирования преобразований основным является режим анализа (вывода информационных портретов, решения обратной задачи декодирования), а режим классификации
является вспомогательным.
Таким образом, в подсистемах идентификации состояния ПС
и формирования преобразований может быть применена одна и
та же система классификации. При этом в этих подсистемах система классификации будет использоваться по-своему: в системе
идентификации используется режим классификации, а в под233
системе формирования преобразований – прежде всего, режим
анализа, а также классификации. В обеих подсистемах используются режимы обучения с учителем и верификации решающих
правил.
Состояние ПС не сводится к значениям метрик. Поэтому необходимо, исходя из того, что целевые состояния ПС известны,
определить приоритетные показатели, играющие основную роль
в детерминации этих состояний.
Для подсистемы формирования преобразований экспертом
формируется база данных, которая представляет собой классификационную выборку. Эта база обрабатывается алгоритмом
классификации, в результате чего формируется основной результат работы подсистемы идентификации: автоматическая
классификация будущих возможных состояний ПС при различных вариантах его преобразований.
Режим классификации не может быть практически использован, пока не сформированы решающие правила, с которыми работает классифицирующий алгоритм, эта функция выполняется
в режиме обучения с учителем (экспертом).
Данный режим в подсистеме формирования преобразований
работает во многом аналогично подсистеме идентификации состояний ПС. Главное отличие вытекает из разной природы задач идентификации и прогнозирования. При идентификации
по актуальным метрикам надо классифицировать актуальное
состояние, а при прогнозировании по прошлым и актуальным
метрикам – классифицировать будущее состояние. Таким образом, различие между этими режимами состоит в содержании исходной информации, а не в методах ее обработки.
При преобразовании неструктурированной информации о вариантах управления в формализованный вид выполняются те
же работы, что и в подсистеме классификации. Экспертами или
путем задания эталонных ПС формируется обучающая выборка.
Последняя по своей структуре похожа на классифицируемую, но
содержит еще и верифицированную классификационную информацию, имеющую прогностическую ценность и предоставляемую экспертами. Обучающая выборка формируется на основе
экспериментальных данных, дополненных их экспертной оценкой. Эта выборка обрабатывается обучающим алгоритмом, который формирует решающие правила (классы, отражающие весь
спектр будущих возможных состояний ПС), а также определяется ценность метрик для решения задач подсистемы идентифи234
кации. Метрики, не имеющие особой прогностической ценности,
могут быть корректным способом удалены из системы. Этот процесс осуществляется с помощью итерационных алгоритмов, при
этом обеспечивается выполнение ряда ограничений, таких, например, как размерность пространства метрик, его информационная избыточность, которые задаются экспертом.
Режим верификации (контроля качества решающих правил)
основан на использовании внутреннего критерия качества алгоритма классификации и может быть выполнен в любой момент
(это должно обязательно делаться после каждой адаптации к
изменениям модели качества ПС, а также по требованию экспертов). Для активизации данного режима обучающая выборка
копируется в классифицируемую, осуществляется ее автоматическая классификация, результаты которой сравниваются с независимой экспертной классификацией. На основе этого рассчитываются как детализированная, так и обобщающая характеристики качества решающих правил.
Переформирование решающих правил (адаптация) не всегда
выполняется только при обнаружении неудовлетворительного
качества работы этих правил, как в алгоритмах перцептронного
типа, а также не только при изменении модели качества ПС. Рационально проводить адаптацию каждый раз, когда становится
доступной новая необходимая для этого информация. Поэтому в
подсистеме идентификации предусмотрен режим дозаписи классифицируемой выборки к обучающей, чтобы в последующем,
когда за счет использования обратной связи станет известна степень соответствия прогноза результатам управления, этой верифицированной информацией дополнить обучающую выборку и
переформировать решающие правила.
На рис. 88 представлен алгоритм управления качеством ПС.
Рассмотрим шаги представленного алгоритма.
Шаг 1. Определение общих требований к качеству ПС: построение модели качества, модели измерений.
На шаге 1 происходит детализация понятия качества ПС. Выбираются характеристики качества, определяются принципы
проектирования. Строится модель качества, включающая характеристики и принципы проектирования как объекты. С помощью морфизмов модели качества отражаются иерархические
и одноуровневые отношения между характеристиками и принципами проектирования. С помощью контравариантного функтора
из модели качества формируется модель измерений, в которой
235
236
ªÇÀ½¹ÆÁ¾Åǽ¾ÄÁ
ÃÇÆÃɾËÆǼǨª
¡Å¾×ËÊØÊÌÒÆÇÊËÁ»
½¾Í¾ÃËÆÔÎÈǽÈÉÇÊËɹÆÊË»¹Î
¹
Рис. 88. Алгоритм управления качеством ПС
¨ÉÇ»¾ÉùÊÇÎɹƾÆÁØÍÌÆÃÏÁÇƹÄÕÆÔÎ
Ê»ÇÂÊË»
œ¾Æ¾É¹ÏÁØÁÊÎǽÆǼÇÃǽ¹Æ¹ÇÊÆÇ»¾
ÈɾǺɹÀÇ»¹ÆÆÇÂÅǽ¾ÄÁ
©¾¹ÄÁÀ¹ÏÁػԺɹÆÆÇÂ
ÈÇÊľ½Ç»¹Ë¾ÄÕÆÇÊËÁÈɾǺɹÀÇ»¹ÆÁÂ
›ÔºÇÉÃÇÅÈľÃÊÆǼÇÈɾǺɹÀÇ»¹ÆÁØȾɾ»Ç½ØÒ¾¼ÇÊÌÒÆÇÊËÁ
¨ªÁÀ½¾Í¾ÃËÆǼǻÖ˹ÄÇÆÆÔÂÃĹÊÊÔÊÇÊËÇØÆÁÂ
¦¾Ë
§Ï¾ÆÁ»¹ÆÁ¾Ã¹Ð¾ÊË»¾ÆÆǼÇÊÇÊËÇØÆÁØÃÇÆÃɾËÆǼǨª
ɹÊÈɾ½¾Ä¾ÆÁ¾ÊÌÒÆÇÊ˾¨ªÈÇÃĹÊʹÅÊÇÊËÇØÆÁÂ
­ÇÉÅÁÉÇ»¹ÆÁ¾ÃĹÊÊǻùоÊË»¾ÆÆǼÇÊÇÊËÇØÆÁبª
ÇÈɾ½¾Ä¾ÆÁ¾ÖÃÊȾÉ˹ÅÁ¼É¹ÆÁÐÆÔÎÀƹоÆÁžËÉÁÃ
½ÄØɹÀÆÔÎÃĹÊÊÇ»ÊÇÀ½¹ÆÁ¾º¹ÀÔ½¹ÆÆÔΨªÁ
ÃĹÊÊÁÍÁùÏÁØÁÎÖÃÊȾÉ˹ÅÁ
§Èɾ½¾Ä¾ÆÁ¾ËÁÈÇ»
ÖľžÆ˹ÉÆÔÎ
ÈɾǺɹÀÇ»¹ÆÁ¨ª
§Èɾ½¾Ä¾ÆÁ¾ÃÇÅÈľÃÊÆÔÎ
ÈɾǺɹÀÇ»¹ÆÁ¨ª
©¹ÀɹºÇËù ž˹ Åǽ¾ÄÁ¨ªsǺӾ½ÁƾÆÁ¾ËÁÈÇ»»¾ÉÑÁÆÁɾº¾É½ÇÊ˹ËÇÐÆÔÎ
½ÄØÍÇÉŹÄÁÀ¹ÏÁÁžËÉÁÃ
§Èɾ½¾Ä¾ÆÁ¾ËɾºÇ»¹ÆÁÂÃùоÊË»ÌÊÌоËÇÅØÀÔùɹÀɹºÇËÃÁ½¾Ë¹ÄÁÀ¹ÏÁØÅǽ¾ÄÁ
ÁÀžɾÆÁÂÈǽºÇɺ¹ÀÇ»ÔÎÁÇÈɾ½¾Ä¾ÆÁ¾ÍÌÆÃÏÁÇƹÄÕÆÔÎÀ¹»ÁÊÁÅÇÊ˾ž¿½Ì
žËÉÁùÅÁ
§Èɾ½¾Ä¾ÆÁ¾ÇºÒÁÎËɾºÇ»¹ÆÁÂÃùоÊ˻̨ª
ÈÇÊËÉǾÆÁ¾Åǽ¾ÄÁùоÊË»¹Åǽ¾ÄÁÁÀžɾÆÁÂ
каждой характеристике, подхарактеристике, принципу проектирования модели качества соответствует производная метрика.
Все эти работы реализуются обобщенно, без учета конкретной
специфики проекта. Формируемые требования по своей природе
являются противоречивыми, здесь на основе работы экспертов
находится компромисс, учитывающий взаимовлияния показателей качества.
Шаг 2. Определение требований к качеству с учетом языка
разработки: детализация модели измерений (подбор базовых и
определение функциональных зависимостей между метриками).
На основе анализа конструкций языка программирования
или моделирования экспертами определяются базовые метрики,
подходящие для оценивания производных метрик. В дальнейшем использованные для определения базовых метрик языковые конструкции ложатся в основу типов вершин и ребер графовой модели ПС. Объекты модели измерений дополняются этими
базовыми метриками. Экспертами детализируются морфизмы
модели измерений для задания функциональных зависимостей
между объектами модели измерений.
Шаг 3. Разработка (мета-)модели ПС – объединение типов
вершин и ребер, достаточных для описания метрик.
На основе анализа модели качества выбираются значимые
сущности и отношения ПС, которые становятся типами вершин
и ребер. Важно отметить, что отсутствует необходимость моделирования всех конструкций языка, модель ПС должна описывать
только те из них, которые отвечают оценке качества в соответствии с определенной моделью качества. Решение о составе множества языковых конструкций, подлежащих моделированию,
принимается на основе модели измерений при определении набора базовых метрик для оценивания производных.
Шаг 4. Определение типов элементарных преобразований ПС.
Формируется перечень элементарных преобразований, базис
которых представляет собой удаление и добавление вершины
или ребра каждого типа. Дополнительно могут определяться
такие операции, как переименование, изменение типа и другие
преобразования ПС.
Шаг 5. Формирование классов качественного состояния ПС
(определение экспертами граничных значений метрик для разных классов, создание базы данных ПС и классификация их экспертами или системой на основе репозитория ПС).
237
Информация о модели измерений, ПС и элементарных преобразованиях поступает на вход подсистемы обучения с учителем.
Эксперты сообщают системе диапазоны значений метрик для
всех типов программных сущностей. Выбираются шкалы оценки состояний (например, «эталонное», «дефектное»). На вход системы также могут быть поданы ПС, состояние качества которых
заранее известно, таким образом формируется репозиторий ПС.
Система фиксирует значения метрик программных сущностей
этих ПС. Эксперты анализируют и корректируют результаты
анализа ПС системой. Таким образом формируется обучающая
выборка.
Эта обучающая выборка обрабатывается обучающим алгоритмом, на основе чего им формируются решающие правила (классы состояний ПС, отражающие весь спектр будущих возможных
состояний), а также определяется ценность метрик для возможного снижения размерности метрического пространства.
Метрики, не имеющие особой прогностической ценности, могут быть удалены из системы.
Шаг 6. Определение комплексных преобразований ПС.
На основе метамодели на шаге 4 формируются элементарные
преобразования. На данном шаге эти элементарные преобразования комбинируются в комплексные. Каждое комплексное преобразование соответствует приведению сущности ПС из одного
класса состояния в другое.
Шаг 7. Создание модели конкретного ПС.
На основании определенных типов вершин и ребер строится
модель ПС, качество которой подлежит оценке.
Шаг 8. Оценивание качественного состояния конкретного ПС
(распределение сущностей ПС по классам состояний).
Осуществляется применение решающих правил, выработанных на шаге 5. В подсистеме идентификации предусмотрен режим дозаписи классифицируемой выборки к обучающей, чтобы
в последующем, когда станет известна степень соответствия прогноза результатам преобразований ПС, этой верифицированной
оценочной информацией дополнить обучающую выборку и переформировать решающие правила. Таким образом реализуется
обучающая обратная связь.
Шаг 9. Выбор комплексного преобразования, переводящего
сущности ПС из дефектного в эталонный классы состояний.
Из сформированных на шаге 6 типов преобразований выбирается комплексное преобразование или их композиция, которая
238
сможет перевести сущности ПС, находящиеся в классе состояний, который был оценен как дефектный, в класс эталонного состояния. Комплексное преобразование ищется на основе операторов того метрического пространства, метрика которого ниже
эталонной. Это комплексное преобразование проходит процедуру оптимизации, состоящую в выборе за счет операторов комплексирования и процедуры нормализации минимально трудоемкой, потенциально менее опасной композиции элементарных
преобразований.
Шаг 10. Реализация выбранной последовательности преобразований.
На данном шаге происходит реализация выбранного на шаге 9
комплексного преобразования или их композиции.
Шаг 11. Генерация исходного кода на основе преобразованной модели.
Происходит генерация исходного кода на целевом языке системы.
Шаг 12. Проверка сохранения функциональных свойств.
Осуществляется путем компиляции исходного кода, сгенерированного на шаге 11, получения исполняемых модулей ПС и запуска пакета функциональных тестов, состав которого позволяет сделать вывод о том, что осуществленные преобразования не
повлияли на функциональные свойства ПС.
Шаг 13. Повтор шагов 7–12 до тех пор, пока качественное состояние ПС не будет соответствовать эталонному.
Шаг N. Верификация решающих правил.
Если решающие правила построены и оптимизированы, но
качество их работы неизвестно, то пользоваться ими для принятия решений было бы опрометчиво. Верификация решающих
правил основана на использовании внутреннего критерия качества алгоритма классификации и может быть выполнена в любой
момент, например, по требованию экспертов, в обязательном порядке − после каждой адаптации к изменению модели качества.
Для выполнения данной функции обучающая выборка копируется в классифицируемую, осуществляется ее автоматическая
классификация, ее результаты сравниваются с независимой экспертной классификацией. На основе этого рассчитываются показатели качества решающих правил (все эти работы полностью
автоматизированы).
239
Глава 6. Программное обеспечение
для управления качеством
Для практического апробирования представленных моделей
и методик управления качеством программных средств было
инициировано шесть проектов, в результате которых были созданы следующие программы:
1) программное средство анализа кода для рефакторинга
(ПСАКР);
2) программное средство автоматизации пользовательского
рефакторинга (ПСАПР);
3) программное средство детектирования дефектов кода
(ПСДДК);
4) программное средство метрического анализа кода
(ПСМАК);
5) программное средство оценки качества программ
(ПСОКП);
6) программное средство рефакторинга моделей программ
(ПСРМП).
Каждое из программных средств обладает функциональной
целостностью и реализует подмножество предлагаемых методик
по работе над качеством программ.
В табл. 27 представлены сведения о теоретическом базисе разработанных ПС управления качеством.
Таблица 27
Теоретический базис разработанных ПС управления качеством
Функция
ПСАКР ПСАПР ПСДДК ПСМАК ПСОКП ПСРМП
Модель качества ПС Неявно Неявно Неявно
Модель ПС
+
+
+
Модель измерений
+
+
+
ПС
Модель преобразо+
+
–
ваний ПС
Алгоритм оценива+
+
+
ния качества ПС
Алгоритмы преоб+
+
–
разований ПС
Алгоритм управле+
+
–
ния качеством ПС
240
+
+
+
+
+
+
Неявно
+
+
–
–
+
+
+
+
–
–
+
–
–
+
В табл. 28 представлены сводные данные о программах, созданных в рамках разработки системы управления качеством
ПС.
Таблица 28
Сводные данные о разработанных ПС
Функция
Моделирование
качества ПС
Оценивание
качества ПС
Объект анализа
Низкоуровневые
преобразования
Преобразования
по направлению к
шаблонам проектирования
Фильтрация сущностей объекта
анализа по наличию
дефектов
Задание шаблонов
поиска
Задание и выполнение пользовательских последовательностей
преобразований кода
Оптимизация процесса оценивания
качества и преобразований
Добавление других
языков для анализа
Создание новых
метрик
Создание новых преобразований
ПСАКР ПСАПР ПСДДК ПСМАК ПСОКП
ПСРМП
Нет
Нет
Нет
Да
Да
Нет
Да
Да
Да
Да
Да
Да
Исход- Исход- Исход- Исход- Исходный
ный
ный
ный
ный
код на код на код на код на код на
C++
Java
Java
C++
C#
Нет
Да
Нет
Нет
Да
Проект в
виде диаграммы
классов
UML
Да
Да
Да
Нет
Нет
Нет
Да
Да
Да
Да
Да
Нет
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Да
Нет
Нет
Нет
Да
Нет
Нет
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Да
Нет
Нет
Нет
Да
241
Ниже представлены краткие аннотации разработанных программных средств. Для апробирования разработанных средств
были выбраны два программных проекта – «Базикмед» [145]
и «Телемед». Проект «Базикмед» разрабатывался с 1998 по
2006 гг., цель разработки – создание системы автоматизации
технологических процессов военных лечебных учреждений Министерства обороны РФ. Проект был построен с использованием
трехуровневой архитектуры, компоненты бизнес-логики были
написаны на Java, составили порядка 800 классов. Проект «Базикмед» содержит отдельный модуль построения отчетов, написанный на С#. Проект «Телемед» был посвящен созданию программной системы для телемедицинских консультаций, создавался с 2000 по 2006 гг. Специальное программное обеспечение
(СПО) проекта «Телемед» содержит около 500 классов на языке
C++.
Все работы по улучшению качества ПС «Базикмед» и «Телемед» были произведены в период доработки опытных образцов
по результатам государственных испытаний. Работы по качеству
касались структуры опытных образцов изделий и не затронули
функциональных свойств.
С целью оценивания работы разработанных ПС управления
качеством была создана экспертная комиссия. Состав комиссии
указан в табл. 29.
Таблица 29
Состав экспертной комиссии для оценивания работы ПС
управления качеством
Должность
Предприятие
Количество
Доцент
Инженер-программист
Инженер-программист
ГУАП
Sun Microsystems
Alcatel-Lucent
3
3
3
В качестве методов математической обработки экспертных
оценок использовались проверка согласованности мнений экспертов и усреднение мнений экспертов внутри согласованной
группы.
Экспертная комиссия провела инспекцию исходного кода и
моделей программных средств, подвергаемых качественному
анализу. Результат обработки экспертных оценок приведен в
табл. 30.
242
Таблица 30
Результат анализа наличия дефектов экспертной комиссией
Исследуемое программное средство
Исходный код (C#) СПО модуля генерации отчетности
«Базикмед»
Исходный код (C++) СПО «Телемед»
Исходный код (Java) компонентов бизнес-логики СПО
«Базикмед»
Количество
дефектов
18
29
43
6.1. Программное средство анализа кода
для рефакторинга
Программное средство анализа кода для рефакторинга
(ПСАКР) было зарегистрировано в отраслевом фонде алгоритмов
и программ 4 марта 2008 г. [148].
Теоретическую основу ПСАКР составляют модель качества
ПС (неявно), модель ПС, модель измерений ПС, модель преобразований ПС, алгоритм оценивания качества ПС, алгоритмы преобразований ПС, алгоритм управления качеством ПС.
6.1.1. Функциональное назначение
ПСАКР предназначено для автоматизации первичной стадии
рефакторинга – поиска фрагментов программного кода, подлежащих рефакторингу. Основной целью автоматизации процедуры рефакторинга является выявление и исправление очевидных
ошибок без участия программиста, а также оказание программисту, решившему провести рефакторинг, экспертной помощи
по оцениванию потенциальных проблем в существующем коде.
Функции ПСАКР:
– анализ исходного кода программ с применением паттернов
рефакторинга;
– возможность добавления новых паттернов рефакторинга;
– генерация отчетов о возможных проблемах анализируемого
исходного кода;
– просмотр всей собранной информации на этапе лексического и синтаксического анализа;
– поддержка запросов к базе данных, хранящей данные об исходном коде, необходимые для анализа;
– поддержка автоматического последовательного запуска набора паттернов рефакторинга для комплексного анализа кода.
243
Основные свойства ПСАКР:
1) полноценная поддержка грамматики языка С++. Наличие
полноценного парсера и лексического анализатора языка программирования С++ является фундаментом ПСАКР. Имея анализатор кода, можно добавлять поддержку других языков программирования;
2) поддержка базы данных SQLite 3.0 для хранения информации об исходном коде программы. За это отвечает ряд классов на
языке С++, с помощью которых можно изменять структуру таблиц и определять набор данных, который будет экспортирован.
Создание такой объектной модели над базой данных позволит в
дальнейшем использовать преимущества повторного использования кода и легко расширять систему;
3) возможность доступа к содержимому базы данных, для
внешних клиентов. Для доступа к содержимому базы данных
разработанной системы внешними клиентами существует COM
компонента, позволяющая работать с созданными базами данных и осуществлять SQL-запросы к их содержимому;
4) использование скриптов для описания паттернов рефакторинга. Для реализации самих паттернов рефакторинга был выбран
скриптовый язык Javascript. Создан и определен формат скриптов, а также существует возможность автоматического запуска
подмножества всех зарегистрированных в каталоге паттернов;
5) генерация отчетов о потенциальных проблемах в анализируемом коде. Скриптовый модуль используется для последовательного запуска всех зарегистрированных паттернов и формирования
HTML-отчета о состоянии дел программного проекта.
6.1.2. Результаты использования
Для анализа функциональных возможностей ПСАКР было
применено к исходному коду СПО «Телемед». В результате было
выявлено 32 фрагмента кода, потенциально подходящих для рефакторинга. Из них 27 совпали с дефектами, обнаруженными
экспертной комиссией.
6.2. Программное средство автоматизации
пользовательского рефакторинга
Программное средство автоматизации пользовательского рефакторинга (ПСАПР) было зарегистрировано в отраслевом фонде
алгоритмов и программ 4 марта 2008 г. [149].
244
Теоретическую основу ПСАПР составляют модель качества
ПС (неявно), модель ПС, модель измерений ПС, модель преобразований ПС, алгоритм оценивания качества ПС, алгоритмы преобразований ПС, алгоритм управления качеством ПС.
6.2.1. Функциональное назначение
ПСАПР ставит своей целью расширить возможности программиста по реорганизации кода, позволяя задавать пользовательские преобразования и использовать экспертные данные для
оценивания критических участков исходного кода и его дальнейшего изменения. В табл. 31 представлено сравнение основных средств разработки объектно-ориентированных программ с
ПСАПР.
Таблица 31
Сравнение функциональных возможностей средств разработки
в контексте ПСАПР
Возможность
Eclipse
Низкоуровневые реорганизации кода
Да
Рефакторинг по направлению к шаблонам проектирования
Нет
Visual
Studio
Да
ПСАПР
Только
самые
примитивные
Нет
Только
самые
примитивные
Нет
Нет
Наследуются от
платформы
Eclipse
Да
Нет
Да
Да
Да
Да
Нет
Да
Да
Нет
Нет
Нет
Нет
Нет
Нет
Да
Java/
любой
Java/
любой
Java/
любой
C#,
VB.NET
Java
Анализ кода и выявНет
ление дефектов
Семантический поиск Ограничен
в коде
встроенным
набором
структур
поиска
Задание шаблонов
Нет
поиска
Задание и выполнение пользовательских
последовательностей
реорганизаций кода
Язык реорганизуемого кода
IntelliJ
NetBeans
IDEA
Да
Да
245
Окончание табл. 31
Возможность
Доступность
Расширяемость
IntelliJ
NetBeans
IDEA
Open-source
99–
Open499 $
source
Да
Да
Да
Eclipse
Visual
Studio
299–
2799 $
Нет
ПСАПР
Open-source
Да
ПСАПР представляет собой программное средство автоматизации модификации качественных свойств программного обеспечения и предназначено для выполнения композитных рефакторингов, составленных пользователем, которые изменяют качественное состояние кода.
ПСАПР представляет собой плагин к платформе Eclipse. Он
предназначен для облегчения процесса написания кода на языке
программирования Java в среде IDE Eclipse и повышения его эффективности за счет удаления дефектов кода.
ПСАПР выполняет следующие функции:
– формирование шаблонов комплексных преобразований кода
как композиции элементарных (программных) и комплексных
(пользовательских). Шаблон задается как набор типов объектов,
которым впоследствии сопоставляются реальные объекты и над
которыми проводятся преобразования, а также список самих
шагов преобразования. Объектами также выступают результаты выполнения шагов преобразований, если пользователь не отключил эту возможность для шага и задал для результата имя.
Сами элементарные преобразования жестко зафиксированы в
программе и не доступны пользователю для изменения. Их базу
составляют элементарные рефакторинги, доступные в системе
Eclipse, а также добавленные из подключаемого плагина;
– выбор метрик для оценивания необходимости применения
каждого из пользовательских рефакторингов;
– задание экспертных значений метрик для каждого пользовательского рефакторинга для выделения кода, нуждающегося
в реорганизации;
– поиск шаблона преобразования среди пользовательских,
наиболее подходящего для применения к выделенному пользователю участку кода;
– сохранение пользовательских шаблонов между сессиями;
– поддержание целостности кода и возможность отката транзакции, в которой выполняются преобразования;
246
– информирование пользователя об ошибках выполнения
композитного преобразования;
– сопоставление пользовательского шаблона с реальными
объектами Java-модели кода и выполнение преобразований, заданных в нем.
Элементарные преобразования, реализованные в ПСАПР
1. Rename method – изменение имени метода. Для выполнения преобразования необходимо задать метод, который будет
подвержен изменению, и новое имя метода. Предусловием является уникальность имени в пространстве имен заданного класса.
Результатом преобразования выступает переименованный метод.
2. Create class – создание нового пустого публичного класса
верхнего уровня. Для выполнения преобразования необходимо
задать имя создаваемого класса и пакет, в который новый класс
будет помещен. Предусловием является уникальность имени в
пространстве имен пакета. Результатом преобразования выступает созданный класс.
3. Create method – создание нового метода. Для выполнения
преобразования необходимо задать тело метода и класс, в котором он будет создан. Предусловием является уникальность имени нового метода в пространстве имен заданного класса и синтаксическая правильность конструкции тела метода. Результатом
преобразования выступает созданный метод.
4. Create package – создание нового пустого пакета. Для выполнения преобразования необходимо задать имя создаваемого
пакета и пакет, в который новый будет помещен. Предусловием
является уникальность имени в пространстве имен пакета. Результатом преобразования выступает созданный пакет.
5. Move method – перемещение статического или нестатического метода. Для выполнения преобразования необходимо задать перемещаемый метод и класс, в который этот метода будет
перенесен. Предусловием является наличие в классе, из которого переносится метод, поля типа, в который метод перемещается. Результатом преобразования выступает перемещенный метод.
6. Convert anonymous class to nested – создание закрытого
внутреннего класса на базе анонимного. Для выполнения преобразования необходимо задать анонимный класс и имя нового
внутреннего класса. Предусловием является уникальность име247
ни в пространстве имен класса верхнего уровня, содержащего
внутренний. Результатом преобразования выступает созданный
внутренний класс.
7. Convert inner class to top level – создание публичного класса
верхнего уровня на базе вложенного. Для выполнения преобразования необходимо указать внутренний класс, который будет
подвержен модификации. Предусловием является уникальность
имени внутреннего класса в пространстве имен пакета, в котором создается класс. Результатом преобразования выступает созданный класс.
8. Extract interface – выделение интерфейса. Для выполнения
преобразования необходимо задать класс, из которого выделяется интерфейс, и имя создаваемого интерфейса. Предусловием является уникальность имени интерфейса в пространстве имен пакета, содержащего базовый класс. Результатом преобразования
выступает созданный интерфейс.
9. Inline method – замещение всех вызовов метода выполнением его тела. Для выполнения преобразования необходимо задать
метод, который будет удален.
10. Generate getter and setter – создание методов доступа к
полю. Для выполнения преобразования необходимо задать поле,
для которого будут созданы методы. Предусловием является отсутствие методов с именами get<имя поля> и set<имя поля> в
пространстве имен класса поля.
11. Introduce factory – замена конструктора фабричным методом. Для выполнения преобразования необходимо задать конструктор, который будет удален. Предусловием является отсутствие метода create<имя класса конструктора> в пространстве
имен класса. Результатом преобразования выступает созданным
фабричный метод.
12. Generate singleton – создание класса по паттерну проектирования «синглетон». Для выполнения преобразования необходимо задать имя нового класса и пакет, в котором он будет создан. Предусловием является уникальность имени нового класса
в пространстве имен пакета. Результатом преобразования выступает созданный класс.
13. Pull up method – поднятие метода вверх на одну ступень по
иерархии наследования. Для выполнения преобразования необходимо задать метод, который будет перемещен. Предусловием
является наличие базового класса у того, из которого берется ме248
тод, а также уникальность имени перемещаемого метода в пространстве имен его нового класса. Результатом преобразования
выступает перемещенный метод.
14. Push down method – перенос метода вниз по иерархии наследования. Для выполнения преобразования необходимо задать
метод, который будет перемещен. Предусловием является наличие у класса, содержащего перемещаемый метод, наследников, а
также тот факт, что в классах-приемниках имя перемещаемого
метода уникально.
15. Delete method – удаление метода. Для выполнения преобразования необходимо задать метод, который будет удален.
16. Rename field – переименование поля. Для выполнения
преобразования необходимо задать поле, которое будет переименовано, и его новое имя. Предусловием является уникальность
нового имени в пространстве имен класса поля. Результатом преобразования выступает переименованное поле.
17. Move field – перенос поля. Для выполнения преобразования необходимо задать поле, которое будет перенесено, и классприемник. Предусловием является уникальность имени поля
в пространстве имен класса-приемника. Результатом является
перенесенное поле.
18. Create field – создание поля. Для выполнения преобразования необходимо задать класс, в котором будет создано поле, и
строку его объявления. Предусловием является уникальность
имени поля в пространстве имен класса, в котором это поле будет создано. Результатом преобразования выступает созданное
поле.
19. Move class – перенос класса. Для выполнения этого преобразования необходимо задать переносимый класс и пакет, куда
этот класс переносить. Предусловием является уникальность
имени класса в пространстве имен его нового пакета. Результатом преобразования выступает перенесенный класс.
Метрики для формирования оценки необходимости применения
преобразований
1. Number of classes – общее количество классов в сегменте
(проекте, пакете, классе).
2. Number of children – общее количество прямых подклассов
класса. Класс, реализующий интерфейс, рассматривается как
его прямой потомок.
249
3. Number of interfaces – общее количество интерфейсов в сегменте.
4. Depth of inheritance tree (DIT) – расстояние от класса Object
в дереве наследования.
5. Number of overridden methods (NORM) – общее количество методов в сегменте, которые перекрывают методы базового
класса.
6. Number of methods (NOM) – общее количество методов,
определенных в сегменте.
7. Number of fields – общее количество полей, определенных
в сегменте.
8. Total lines of code (TLOC) – общее количество строк кода, в
которые попадают пустые строки и комментарии.
9. Method lines of code (MLOC) – общее количество строк кода,
которые находятся внутри тел методов, включая пустые строки
и комментарии.
10. Specialization index – среднее значение специализированного индекса, высчитываемое как NORM * DIT / NOM. Это метрика уровня классов.
11. McCabe Cyclomatic Complexity – количество «развилок»
кода в сегменте. Каждый раз, когда в коде возникает разветвление (if, for, while, do, case, catch, ?: и т. д.), значение метрики
увеличивается на 1. Это метрика уровня методов.
12. Weighted Methods per Class (WMC) – сумма McCabe
Cyclomatic Complexity для всех методов класса.
13. Lack of Cohesion of Methods (LCOM) – степень сцепления.
Вычисляется по методу Henderson-Sellers. Если m(A) – это количество методов, использующих атрибут A, вычисляется среднее
значение m(A) для всех атрибутов, вычитается количество методов m и результат делится на (1–m). Маленькое значение говорит
о высоком сцеплении класса, а значение, близкое к 1, – о недостатке сцепления и предполагает необходимость преобразований
для разбиения этого класса.
6.2.2. Результаты использования
Для анализа функциональных возможностей ПСАПР было
применено к исходному коду СПО «Базикмед». До начала использования ПСАПР претерпела настройку диапазонов значений метрик для применения рефакторинга, также были созданы
несколько типов комплексных преобразований. В результате
было выявлено 35 фрагментов кода, потенциально подходящих
250
для комплексного рефакторинга по установленным значениям
метрик. Из 35 выявленных дефектов 33 вошли в число 43-х дефектов, выявленных экспертной комиссией. Затем 33 найденных ПСАПР и соответствующие мнению экспертов комплексных
рефакторинга были реализованы. Последующее модульное тестирование подтвердило, что в результате рефакторинга не было
внесено ошибок, и функциональные свойства СПО «Базикмед»
не изменились.
6.3. Программное средство детектирования
дефектов кода
Программное средство детектирования дефектов кода
(ПСДДК) было зарегистрировано в отраслевом фонде алгоритмов
и программ 4 марта 2008 г. [150].
Теоретическую основу ПСДДК составляют модель качества
ПС (неявно), модель ПС, модель измерений ПС и алгоритм оценивания качества ПС.
6.3.1. Функциональное назначение
Особенностями дефектов кода является отсутствие явных признаков их проявления. Если ошибки кода могут быть выявлены за
счет правильно выбранной методики тестирования программы,
то дефекты кода с помощью тестирования выявить невозможно –
в присутствии дефектов программа работает также безошибочно.
Поэтому был разработан подход к решению проблемы детектирования, основанный на использовании числовых характеристик
программных сущностей – метрик. Понятие метрик достаточно
давно используется в технологии разработки программного обеспечения для оценки трудоемкости, разветвленности программного продукта и т. п. В настоящее время различными авторами
разработано большое количество метрик программного кода,
позволяющих в численном виде оценить разнообразные свойства программных сущностей, такие как связность, сцепление,
модульность классов и пр. Эти метрики легли в основу предложенных систем автоматического определения программных дефектов. С целью автоматизации процесса анализа кода на предмет наличия дефектов было разработано программное средство
детектирования дефектов кода (ПСДДК).
Для организации автоматического детектирования дефектов
формируется так называемая стратегия детектирования (СД),
251
которая основывается на некотором наборе метрик, характеризующих программный дефект. СД представляет собой пороговый фильтр программных сущностей. Если значения метрик
программной сущности лежат в пределах пороговых значений
СД, то принимается решение о принадлежности программной
сущности к соответствующему классу программных дефектов,
в противном случае, программная сущность свободна от данного дефекта. Например, для дефектов типа Data Class (класс используется как репозиторий данных и не содержит явных методов обработки этих данных) стратегия детектирование имеет
вид
DataClass(S) =
"C Ì S '
= S' (WOC(C), BottomValues(T1 )) Ç (WOC(C), LowerThan(T2 )) Ç ,
((NOPA (C), HigherThan(T3 )) È (NOAM(C), LowerThan(T4 )))
где T1, T2, T3, T4 – пороговые значения стратегии детектирования, S – множество классов ОО-кода, S’ – множество классов,
имеющих дефект DataClass, WOC, NOPA, NOAM – метрики кода
(табл. 32). Записанную таким образом СД можно представить в
виде бинарного дерева решений, изображенного на рис. 89.
Таким образом, СД формально включает в себя три связанных
друг с другом элемента: набора метрик программного дефекта,
правила фильтрации (или конфигурации бинарного дерева решений) и набора пороговых значений.
/0".5
$‹4o
/01"5 $Œ4o
5 80$5
$Œ4o
$‹4o
Рис. 89. Дерево решений стратегии детектирования дефекта ОО-кода
типа DataClass
252
В табл. 32 приведен список метрик, составляющих основу для
реализации стратегий детектирования.
Таблица 32
Объектно-ориентированные метрики, реализованные в ПСДДК
Сокращение
NORM
NOF
NSC
NOC
MLOC
NOM
NBD
DIT
NOP
CA
NOI
VG
TLOC
RMI
PAR
LCOM
CE
NSM
RMD
RMA
SIX
WMC
NSF
Семантика
Количество переопределенных методов класса (Number of
Overridden Methods)
Количество атрибутов класса (Number of Attributes)
Количество потомков класса (Number of Children)
Количество классов (Number of Classes)
Количество строк метода (Method Lines of Code)
Количество методов класса (Number of Methods)
Глубина вложения блока (Nested Block Depth)
Глубина дерева наследования (Depth of Inheritance Tree)
Количество пакетов (Number of Packages)
Центростремительное сцепление (Afferent Coupling)
Количество интерфейсов (Number of Interfaces)
Циклическая сложность по МакКейбу (McCabe Cyclomatic
Complexity)
Общее количество строк (Total Line of Code)
Нестабильность (Instability)
Количество параметров (Number of Parameters)
Недостаток сцепления методов (Lack of Cohesion of
Methods)
Центробежное сцепление (Efferent Coupling)
Количество статических методов (Number of Static
Methods)
Нормализованная дистанция (Normalized Distance)
Степень абстракции (Abstractness)
Показатель специализации (Specialization Index)
Взвешенное число методов на класс (Weighted Methods
per Class), сумма McCabe Cyclomatic Complexity для всех
методов класса
Количество статических атрибутов (Number of Static
Attributes)
6.3.2. Результаты использования
В результате апробирования, применяя различные настройки, системе удалось обнаружить до 41 дефекта проектирования в
исходном коде компонент бизнес-логики «Базикмед», входящих
в состав 43, обнаруженных членами экспертной комиссии.
253
6.4. Программное средство метрического анализа кода
Программное средство метрического анализа кода (ПСМАК)
было зарегистрировано в отраслевом фонде алгоритмов и программ 4 марта 2008 г. [151].
Теоретическую основу ПСМАК составляют модель качества
ПС, модель ПС, модель измерений ПС и алгоритм оценивания
качества ПС.
6.4.1. Функциональное назначение
ПСМАК позволяет обрабатывать исходные коды программ
и осуществлять оценку качества с помощью метрик. ПСМАК
предоставляет инструмент, позволяющий пользователю самостоятельно добавлять метрики, рассчитываемые на основании
базовых или раннее созданных метрик, что позволяет настраивать метрический аппарат под конкретный проект. Программная система также имеет возможность построения модели качества в виде дерева, с добавлением метрик к каждому узлу дерева.
ПСМАК имеет систему фильтрации, т. е. определения частей
программы, показатели метрик которых выходят за допустимый
интервал определения. Еще одной особенностью разработанной
системы является сохранение результатов оценивания программного продукта в формате XML, что позволяет использовать
полученные файлы в других программных продуктах, например,
MS Excel, построения графиков и диаграмм (табл. 33).
Таблица 33
Сравнительные характеристики ПСМАК
Параметр
для сравнения
Пользовательский
интерфейс
Количество
анализируемых метрик
Расширяемость и
конфигурирование набора
метрик
254
ПСМАК
SDMetrics
SourceMonitor
Интерфейс построен
на новой библиотеке
Windows Forms платформы.NET
На основе
платформы
Java
Стандартный
GUI Win32
40
33
18
Да
Да
Нет
Окончание табл. 33
Параметр
для сравнения
ПСМАК
SDMetrics
Анализ на
основе количественных
показателей
Имеет конфигурируе- Имеет конмые модели качества, фигурируефункции фильтрации мые модели
по параметрам
качества
Сохранение в XML,
Графики,
c возможностью по- сохранение в
Отображение
строения графиков в собственном
результатов
Excel по полученному формате, эксфайлу
порт в XML
C++, предусмоОбрабатытрено добавление
Использует
ваемые языки
других объектноUML-диапрограммироориентированных
граммы
вания
языков
Введет множество конВедет log проекта с фигурационУдобство вевременными отмет- ных файлов,
дения проекта
ками
работает с
временными
отметками
SourceMonitor
Показывает в
основном статистические данные, без выводов
Графики, сохранение в собственном формате
*.smp, экспорт в
XML и СSV
C++, C#, Java,
Delphi, VB.NET,
C, HTML, Visual
Basic
Ведет log проекта
с временными отметками
6.4.2. Метрики, реализованные в ПСМАК
В табл. 34 приведены базовые метрики класса, а в табл. 35 –
базовые метрики приложения, используемые в ПСМАК.
Таблица 34
Метрики класса
Метрика
DAM (Data Access
Metric)
Семантика метрики
Отношение числа закрытых атрибутов к общему числу атрибутов, объявленных в классе
MAA (Measure of
Отношение количества атрибутов, унаследоAttribute Abstraction) ванных классом, к общему числу атрибутов
класса
FIN (FAN-IN)
Количество классов-предков данного класса
(высокие величины указывают на чрезмерное
использование множественного наследования)
NOA (Number Of
Ancestors)
Общее число предков класса
255
Продолжение табл. 34
Метрика
Семантика метрики
NPA (Number of
Public Attributes)
Количество атрибутов, объявленных общедоступными в классе
NRA (Number of
Reference Attributes)
Количество указателей и ссылок, использованных в качестве атрибутов класса
PDA (Public Data)
Количество открытых и защищенных данныхчленов класса
NPM (Number of
Parameters per
Method)
Среднее количество параметров на метод
класса
HNL (Class Hierarchy
Nesting Level)
Глубина в иерархии, на которой расположен
данный класс
OCAIC
Количество классов, используемых в качестве
атрибутов данного класса
OCMIC
Количество методов данного класса, которые
имеют в качестве параметров другие классы
IS (Interface size)
Отношение открытых членов класса к общему
числу членов
NOM (Number Of
Methods)
Общее число методов класса
NPM2 (Number
of public instance
methods)
Количество общедоступных методов
SIZE2 (Number of
properties)
Количество атрибутов плюс количество закрытых методов
PrIM (Number of
Private Instance
Methods)
Количество скрытых методов экземпляра
класса
Сцепление класса в
иерархии наследования
Сцепление класса в иерархии наследования –
СКИН –(coupling through inheritance ) определяется как СКИН = глубина класса в дереве
наследования + число детей класса
NMI (Number of
Methods Inherited)
Количество методов, которые класс наследует
NOC (Number Of
Children)
Количество потомков
256
Окончание табл. 34
Метрика
Семантика метрики
Пропорция методов
наследуемых подклассом (PMIS).
Пропорция методов, унаследованных классом
от предков (Proportion of Methods Inherited by
a Subclass-PMIS). Эта метрика вычисляется по
формуле PMIS = NMI /PMI. С помощью этой
метрики вычисляется мера специализации
класса по отношению к его предкам
PMI (Potential
Methods Inherited)
Количество методов, унаследованных классом
от предков, плюс количество методов в самом
классе
CS (Class Size)
Общее количество методов (вместе с закрытыми и наследуемыми методами)
Таблица 35
Метрики приложения
Метрика
amb (maximum breadth
of the object hierarchy)
Семантика метрики
Максимальная ширина иерархии объектов
amd (maximum depth of Максимальная глубина иерархии объектов
the object hierarchy)
NCL (Number of classes) Количество классов
ADI (Average Depth of
Inheritance)
Средняя глубина наследования
ANA (Average Number
of Ancestors)
Среднее количество предков всех классов
SPR (Specialisation
Ratio)
Соотношение количества подклассов к количеству суперклассов
MHF (Method Hiding
Factor)
Отношение суммы всех скрытых методов,
определенных во всех классах, к общему
числу методов, определенных в системе
AIF (Attribute
Inheritance Factor)
Отношение суммы унаследованных атрибутов во всех классах системы к общему числу
доступных атрибутов для всех классов
MIF (Method
Inheritance Factor)
Отношение суммы унаследованных методов
во всех классах к общему числу доступных
методов для всех классов
RDB (Ratio between
Depth and Breadth)
Соотношение между глубиной и шириной в
иерархии классов
257
Окончание табл. 35
Метрика
Семантика метрики
RER (Reuse Ratio)
Соотношение числа суперклассов к общему
числу классов
PMO (Percent of
Potential Method uses
Overridden)
Процент переопределенных методов
6.4.3. Функции, выполняемые ПСМАК
ПСМАК предоставляет пользователю возможность выполнять
следующие функции.
1. Подсчет метрик:
1) подсчет базовых метрик (данный набор метрик не изменяемый);
2) подсчет производных метрик (данный набор метрик рассчитывается на основе базовых метрик и ранее определенных
производных метрик);
3) определение новых производных метрик;
4) настройка интервалов критических значений производных
метрик;
5) фильтрация программы, т. е. определение структурных
фрагментов программы, метрики для которых выходят за интервал определенных критических значений.
2. Анализ данных, полученных при подсчете метрик:
1) построение модели качества – задание иерархической
структуры из характеристик, производных метрик вместе с отношениями между ними (с заданием функциональных зависимостей);
2) оценка значения для каждого элемента модели качества;
3) оценка итогового значения качества.
3. Отображение результатов:
1) представление результатов подсчета метрик в виде таблицы и сохранение в файле xml;
2) представление результатов оценивания по модели качества
в виде таблицы и сохранение в файле xml.
4. Обработка исходных текстов программ разработанных на
объектно-ориентированном языке программирования:
1) поддержка языка C++;
2) возможность добавления в ПСМАК модуля обработки других объектно-ориентированных языков программирования.
258
5. Ведение проекта и операции с файлами, входящими в проект:
1) создание проекта в программе;
2) открытие проекта в программе;
3) ведение журнала действий по проекту.
6.4.4. Результаты использования
Для анализа функциональных возможностей ПСМАК было
применено к исходному коду СПО «Телемед». Вначале был построен набор из 15 производных метрик, которые, по мнению
членов экспертной комиссии, наиболее полно отражают качество СПО проектов со сходной с «Телемед» предметной областью,
типовыми требованиями и т. п., были определены интервалы
критических значений этих метрик. Затем была произведена
фильтрация исходного кода СПО «Телемед» и было обнаружено
23 фрагмента исходного кода с нарушенными значениями критических интервалов производных метрик. Все 23 фрагмента
явились подмножеством 29, обнаруженных экспертной комиссией. По мнению членов экспертной комиссии, с помощью более
точного определения состава производных метрик можно повысить степень распознавания дефектов ПСМАК.
6.5. Программное средство оценки
качества программ
Программное средство оценки качества программ (ПСОКП)
было зарегистрировано в отраслевом фонде алгоритмов и программ 4 марта 2008 г. [152].
Теоретическую основу ПСОКП составляют модель качества
ПС, модель ПС, модель измерений ПС и алгоритм оценивания
качества ПС.
6.5.1. Функциональное назначение
ПСОКП представляет собой систему моделирования, оценивания и повышения качества объектно-ориентированного программного обеспечения. Эта система позволяет строить различные модели качества, обрабатывать исходные коды программ
и оценивать их с помощью объектно-ориентированных метрик
на основе построенных моделей качества. Разработанная система соединила в себе лучшие свойства подобных инструментов:
большой базовый набор объектно-ориентированных метрик и
возможность расширения набора метрик, а также возможность
работы с исходным кодом программы.
259
В ПСОКП используется представление модели качества в виде
совокупности трех моделей: качества, измерений и эталонов.
Модель качества (рис. 90) состоит из множества показателей
качества, представленных в виде иерархической структуры.
Данные показатели являются важными для ПС, при этом их
множество обладает свойством полноты, а элементы его не совмещаются.
Элементы модели:
sÈÇùÀ¹Ë¾ÄÕùоÊË»¹
sÊ»ØÀÕž¿½ÌÖľžÆ˹ÅÁÊÇʾ½ÆÁÎÌÉǻƾÂ
Рис. 90. Модель качества
Модель измерений (рис. 91) строится на основе модели качества путем сопоставления с каждым показателем производной
метрики. Для этого сначала выбирается множество метрик из
набора базовых. Затем с самого нижнего уровня иерархии до
самого верхнего определяется для каждого показателя производная метрика, являющаяся комбинацией метрик нижнего
уровня. С показателями самого нижнего уровня иерархии сопоставляется производная метрика, являющая комбинацией
выбранных базовых метрик. На следующем уровне с каждым
показателем сопоставляется метрика, являющаяся комбинацией производных метрик предыдущего уровня. При этом
в комбинацию производной метрики могут входить только те
метрики, которые сопоставлены с подпоказателями рассматриваемого показателя.
Элементы модели:
sÈÇùÀ¹Ë¾ÄÕùоÊË»¹½ÄØÃÇËÇÉǼÇÇÈɾ½¾Ä¾Æ¹
žËÉÁù
sº¹ÀÇ»¹ØžËÉÁù
sÊ»ØÀÕž¿½ÌÖľžÆ˹ÅÁÊÇʾ½ÆÁÎÌÉǻƾÂ
260
Рис. 91. Модель метрик
Эталонная модель (рис. 91) определяется на базе модели измерений. Для этого каждой производной метрике ставится в соответствие эталонное значение в виде диапазона возможных значений и операция включения/исключения из этого диапазона – in/
out. Если выбрана операция включения, то необходимо, чтобы
вычисленное значение метрики попало в указанный диапазон.
Если выбрана операция исключения, то необходимо, чтобы вычисленное значение находилось вне указанного диапазона.
Элементы модели:
sÈÇùÀ¹Ë¾ÄÕùоÊË»¹½ÄØÃÇËÇÉǼÇÇÈɾ½¾Ä¾Æ¹
žËÉÁù½Á¹È¹ÀÇÆ»ÇÀÅÇ¿ÆÔÎÀƹоÆÁÂ
ÁÇȾɹÏÁØ»ÃÄ×оÆÁØÁÊÃÄ×оÆÁØ
sº¹ÀÇ»¹ØžËÉÁù½ÄØÃÇËÇÉÇÂÇÈɾ½¾Ä¾Æ
½Á¹È¹ÀÇÆ»ÇÀÅÇ¿ÆÔÎÀƹоÆÁÂÁÇȾɹÏÁØ
»ÃÄ×оÆÁØÁÊÃÄ×оÆÁØ
sÊ»ØÀÕž¿½ÌÖľžÆ˹ÅÁÊÇʾ½ÆÁÎÌÉǻƾÂ
Рис. 92. Модель эталонов
261
После построения модели эталонов выбирается ПС, которое
необходимо оценить, высчитываются все выбранные базовые метрики и производные метрики. Полученные значения сравниваются с эталонными.
6.5.2. Функции ПСОКП
ПСОКП предоставляет пользователю возможность выполнять
следующие функции:
– создание моделей качества в соответствии с принятыми обозначениями;
– ведение словаря базовых метрик и словарей метрик конкретной модели качества;
– сохранение словарей метрик и их хранение в формате xml;
– открытие, изменение, сохранение файлов с кодом программ;
– проверка синтаксиса кода программ;
– построение дерева, отображающего структуру анализируемой программы;
– расчет требуемых метрик в соответствии с моделью качества
для анализируемой программы;
– фильтрация и отбор метрик, значения которых не удовлетворяют эталонным значениям показателей качества в модели качества;
– составление отчетов-рекомендаций по исправлению и улучшению показателей качества.
На рис. 93 представлена схема программного средства с распределением его функций по модулям.
6.5.3. Результаты использования
Для анализа функциональных возможностей ПСОКП было
применено к исходному коду на C# СПО модуля генерации отчетности «Базикмед». С помощью графического интерфейса
ПСОКП были разработаны модели качества, определены эталонные значения метрик. Затем на основе обсчета метрик модели
измерений была произведена количественная оценка качества
СПО. Затем исходный код был подвергнут фильтрации, в результате которой были выявлены 14 фрагментов кода, значения метрик которых имели отклонения от допустимого интервала. Все
14 найденных дефектов являются подмножеством множества
из 18 дефектов, найденных членами экспертной комиссии. По
мнению членов экспертной комиссии, с помощью более точного
262
263
¶Ë¹ÄÇÆÆÔ¾ÀƹоÆÁØžËÉÁÃ
s
ªÄÇ»¹ÉÕº¹ÀÇ»ÔΞËÉÁÃ
ªÄÇ»¹ÉÕžËÉÁÃ
Åǽ¾ÄÁùоÊË»¹
©¹ÊÊÐÁ˹ÆÆÔ¾ÀƹоÆÁØžËÉÁÃ
©¹ÊоËÈÉÇÁÀ»Ç½ÆÔΞËÉÁÃ
©¹Êо˺¹ÀÇ»ÔΞËÉÁÃ
¨ÇÊËÉǾÆÁ¾
Åǽ¾ÄÁ
ùоÊË»¹
Рис. 93. Распределение функций по модулям ПСОКП
›ÁÀ̹ÄÕÆǾÈɾ½Ê˹»Ä¾ÆÁ¾ÇËо˹
œ¾Æ¾É¹ÏÁØÇËо˹
¥Ç½ÌÄÕ
ɹÊо˹
žËÉÁÃ
©¹ºÇ˹ÊÇÊÄÇ»¹É¾Åº¹ÀÇ»ÔΞËÉÁÃ
ªÉ¹»Æ¾ÆÁ¾Í¹ÃËÁоÊÃÁÎÀƹоÆÁÂÁÖ˹ÄÇÆÆÔÎ
¥Ç½ÌÄÕ
¼¾Æ¾É¹ÏÁÁ
ÇËоËÇ»
¹½¹ÆÁ¾Ö˹ÄÇÆÆÔÎÀƹоÆÁÂ
ªÇÀ½¹ÆÁ¾ÆÌ¿ÆÔΞËÉÁÃÅǽ¾ÄÁùоÊË»¹
¥Ç½ÌÄÕɹºÇËÔÊÇÊÄÇ»¹ÉØÅÁžËÉÁÃ
¥Ç½¾ÄÕÁÊÎǽÆÇÂÈÉǼɹÅÅÔ
«¾ÃÊËÁÊÎǽÆÇÂÈÉǼɹÅÅÔ
¨ÇÊËÉǾÆÁ¾¼É¹ÍÇ»ÇÂÅǽ¾ÄÁÇËɹ¿¹×Ò¾¾ÊËÉÌÃËÌÉÌÁÊÎǽÆÇÂÈÉǼɹÅÅÔ
¨ÇÊËÉǾÆÁ¾½¾É¾»¹ÊÁÆ˹ÃÊÁоÊÃǼÇɹÀºÇɹ
¨ÉÇ»¾ÉùÊÁÆ˹ÃÊÁʹÁÊÎǽÆÇÂÈÉǼɹÅÅÔ
¥Ç½ÌÄÕÈÉÇ»¾ÉÃÁ¹Æ¹ÄÁÀ¹Á
ɹÀºÇɹÁÊÎǽÆǼÇÃǽ¹
ÈÉǼɹÅÅ
построения моделей качества можно повысить степень распознавания проблемных фрагментов кода. В результате с помощью
ПСОКП был получен набор рекомендаций по улучшению качества модуля генерации отчетности СПО «Базикмед».
6.6. Программное средство рефакторинга
моделей программ
Программное средство рефакторинга моделей программ
(ПСРМП) было зарегистрировано в отраслевом фонде алгоритмов и программ 4 марта 2008 г. [153].
Теоретическую основу ПСРМП составляют модель качества
ПС (неявно), модель ПС, модель измерений ПС, модель преобразований ПС, алгоритм оценивания качества ПС, алгоритмы преобразований ПС, алгоритм управления качеством ПС.
6.6.1. Функциональное назначение
ПСРМП представляет собой плагин, написанный к IntelliJ
IDEA 5.0, и предназначен для облегчения процесса проектирования приложений, повышения их эффективности и улучшения
существующего кода.
ПСРМП выполняет следующие функции:
– анализ недостатков диаграммы классов UML с целью определения благоприятных ситуаций для применения методов рефакторинга;
– предоставление пользователю рекомендуемого списка методов рефакторинга;
– оптимизацию связи между недостатками диаграмм классов
и методами рефакторинга.
В качестве языка программирования ПСРМП использует
язык Java для совместимости с IntelliJ IDEA 5.0. Программа
функционирует при наличии на ПЭВМ установленной JRE 1.5
(Java Runtime Environment версии 1.5). Для создания плагина
использовался открытый функциональный интерфейс, который
в IntelliJ IDEA называется OpenAPI и представляет собой отдельную библиотеку.
Общие сведения о структуре программы представлены на
рис. 94.
Поддерживаемые ПСРМП виды рефакторинга:
1) выделение класса (Extract Class);
2) выделение подкласса (Extract SubClass);
3) выделение интерфейса (Extract Interface);
264
§ºÒÁ¾Ê»¾½¾ÆÁØÇÊËÉÌÃËÌɾ
ÈÉǼɹÅÅÔ
¹ÈÉÇÊƹ¹Æ¹ÄÁÀ
½Á¹¼É¹ÅÅÔÃĹÊÊÇ»
§ºÓ¾½ÁƾÆÁ¾Å¾ËÉÁÃÁ
žËǽǻɾ͹ÃËÇÉÁƼ¹
™Æ¹ÄÁÀ
½Á¹¼É¹ÅÅÔ
ÃĹÊÊÇ»
­ÇÉÅÁÉÇ»¹ÆÁ¾ÃĹÊʹ
Êǽ¾É¿¹Ò¾¼ÇÁÆÍÇÉŹÏÁ×
Çƾ½ÇÊ˹ËùνÁ¹¼É¹ÅÅÔ
»ÊÇÇË»¾ËÊË»ÁÁÊžËÉÁùÅÁ
¦¾ÌžÊËƹغÄÁÀÇÊËÕ
£Ä¹Êʽ¹ÆÆÔÎ
¦¾Èɹ»ÁÄÕÆÇÀ¹½ÌŹÆƹØ
Á¾É¹ÉÎÁØ
œ¾Æ¾ËÁоÊÃÁÂ
¹Ä¼ÇÉÁËÅ
¦¹Ð¹ÄÕƹØÈÇÈÌÄØÏÁØ
ªÃɾÒÁ»¹ÆÁ¾
§ËºÇÉ
ªËɾÄÕº¹½ÉǺÕ×
«¾ÇɾËÁоÊùØǺÒÆÇÊËÕ
§½¾É¿ÁÅÇÊËÕÖľžÆ˹ÉÆÔÅÁËÁȹÅÁ
ªÈÁÊÇÃȹɹžËÉÇ»
¦¹Ð¹ÄÕÆǾÈɹ»ÁÄÇ
½ÄØɾ͹ÃËÇÉÁƼ¹
ª¾Ä¾ÃÏÁØȹÉÔ
¥Ì˹ÏÁÁ
¨ÇÊËÉǾÆÁ¾
ɾѾÆÁØ
¦Ç»Ç¾Èɹ»ÁÄÇ
½ÄØžËǽǻ
ɾ͹ÃËÇÉÁƼ¹
šÇÄÕÑÇÂÃĹÊÊ
¤¾ÆÁ»ÔÂÃĹÊÊ
©¾Ñ¾ÆÁ¾
Рис. 94. Структура ПСРМП
4) дублирование видимых данных (Duplicate Observed Data);
5) сохранение всего объекта (Preserve Whole Object);
6) введение граничного объекта (Introduce Parameter Object);
7) замена массива объектом (Replace Array with Object);
8) свертывание иерархии (Collapse Hierarchy);
9) встраивание класса (Inline Class);
10) замена наследования делегированием (Replace Inheritance
with Delegation);
11) инкапсуляция поля (Encapsulate Field);
12) инкапсуляция коллекции (Incapsulate Collection);
13) сокрытие метода (Hide Method);
14) подъем тела конструктора (Pull Up Constructor Body).
Оптимизация связываний недостатков проектных решений
с методами рефакторинга. Генетический алгоритм
При обнаружении большого количества недостатков в программной модели очень сложно априори определить, какие рефакторинги будут использоваться, а какие стоит отложить на
потом или вообще не использовать. Для того чтобы связать недостатки модели ПО и методы рефакторинга, ПСРМП использует
генетический алгоритм.
265
Таблица 36
Метрики, по которым определяются недостатки ПС в ПСРМП
1
Минимальное количество методов в классе
2
Минимальное количество полей в классе
3
Максимальное количество методов в классе
4
Максимальное количество полей в классе
5
Максимальное количество параметров метода
6
Класс является интерфейсом
7
Класс является абстрактным
8
Метод возвращает коллекцию
9
Метод является методом типа get
10
Метод является методом типа set
11
Метод является методом типа is
12
Метод является методом типа has
13
Поле с видимостью public
14
Наличие родительского класса
15
Наличие подкласса
16
Поля с идентичными префиксами в имени
17
Методы с идентичными именами
18
GUI класс
19
Поле с префиксом start в имени
20
Поле с префиксом end в имени
21
Идентичные поля в разных классах
22
Идентичные параметры в нескольких сигнатурах методов
23
Поле является массивом
24
Методы родительского класса с видимостью public
25
Метод является конструктором
26
Поле типа final static
ПСРМП позволяет выявлять недостатки диаграмм классов и
предоставляет рекомендации по рефакторингу анализируемой
системы (табл. 36).
266
Применение генетического алгоритма в качестве метода оптимизации связывания метрик и методов рефакторинга помогло
избежать формальных ошибок, связанных с построением списка
рекомендуемых методов рефакторинга.
Преимущества ПСРМП перед аналогами:
− анализ диаграмм классов и формирование рекомендуемых
методов рефакторинга с применением генетического алгоритма,
что позволяет избежать некорректных рекомендаций;
− гибкость системы с точки зрения формирования схемы применяемой модификации.
6.6.2. Результаты использования
Для анализа функциональных возможностей ПСРМП было
применено к модели компонентов бизнес-логики СПО «Базикмед», выраженной диаграммами классов UML. В качестве результатов, согласно с настроенными метриками и аппаратом рефакторинга, система определила целесообразность проведения
модификации для 54 классов модели. Модификации касались
как внутреннего устройства классов, так и отношений между
ними. Эти модификации покрыли 37 из 43 обнаруженных экспертной комиссией дефектов. По мнению членов экспертной комиссии, более точная настройка метрического аппарата и связей
метрик с рефакторингами позволит повысить степень обнаружения дефектов в классах и отношениях между ними. Был проведен рефакторинг 54 классов, экспертная комиссия подтвердила
корректность проведенных модификаций.
6.7. Результаты практического использования разработанных
программных средств
В табл. 37 представлены сводные данные о результатах применения программ, созданных в рамках разработки системы
управления качеством ПС.
Средства управления качеством применялись к СПО «Телемед» и «Базикмед» в рамках реализации рекомендаций Комиссии по государственным испытаниям. В результате анализа
работы средств управления качеством коллективом экспертов
было отмечено общее повышение качества СПО «Телемед» и «Базикмед», в частности:
1) увеличение полноты реализации принципов проектирования за счет инструментов разработки производных метрик, соот267
268
ПСМАК
ПСДДК
ПСАПР
ПСАКР
Программное средство
Действия
Применение системы с
параметрами, установленными по умолчанию
Осуществлена настройка диапазонов значений
метрик для применения
рефакторинга, созданы несколько типов комплексных преобразований
Реализация комплексных
рефакторингов, модульное
тестирование
Исходный код
Применение различных
(Java) компонен- вариантов настройки генетов бизнес-логики тического алгоритма
СПО «Базикмед»
Исходный код
Построен набор из 15
(C++) СПО «Теле- производных метрик,
мед»
определены интервалы
критических значений.
Произведена фильтрация исходного кода СПО
«Телемед»
Исходный код
(C++) СПО «Телемед»
Исходный код
(Java) компонентов бизнес-логики
СПО «Базикмед»
Исследуемое
программное
средство
Выявлено 27
из 29 дефектов
Выявлено 33
из 43 дефектов
Сопоставление
с оценками
экспертной
комиссии
Таблица 37
Обнаружено 23 дефекта, при более
точном определении производных
метрик степень распознавания
дефектов повышается
Выявлено 23
из 29 дефектов
Функциональные свойства СПО
«Базикмед» не изменились, структурные свойства улучшились
Выявлен 41
Выявлено до 41 дефекта при различных настройках генетического из 43 дефекалгоритма
тов
Выявлено 32 фрагмента кода,
потенциально подходящих для
рефакторинга
Выявлено 35 фрагментов кода,
потенциально подходящих для
комплексного рефакторинга по
установленным значениям метрик
Результат
Сводные данные о результатах применения разработанных ПС
269
ПСРМП
ПСОКП
Программное средство
Действия
Разработаны модели
качества, определены эталонные значения метрик,
произведена количественная оценка качества СПО,
исходный код подвергнут
фильтрации
Модель (диаграм- Применение средства
мы классов UML) с настроенными метрикакомпонентов
ми и аппаратом рефактобизнес-логики
ринга по умолчанию
СПО «Базикмед»
Исходный код
(C#) СПО модуля
генерации отчетности «Базикмед»
Исследуемое
программное
средство
Выявлено 14
из 18 дефектов
Выявлено 37
из 43 дефекта. Экспертная комиссия
подтвердила
корректность
проведенного
рефакторинга
Определена целесообразность
проведения рефакторингов для
54 классов модели, более точная
настройка метрического аппарата
и связей метрик с рефакторингами
позволит повысить степень обнаружения дефектов.
Рефакторинг был реализован для
54 классов
Сопоставление
с оценками
экспертной
комиссии
Выявлено 14 дефектов кода,
с помощью более точного моделей
качества можно повысить степень
распознавания дефектов
Результат
Окончание табл. 37
ветствующих тому или иному принципу проектирования, с последующим мониторингом значений этих метрик;
2) повышение оперативности работ по управлению качеством
программных средств за счет автоматизации процессов поиска
дефектов и выполнения преобразований программ;
3) уменьшение совокупных затрат на разработку за счет контроля соответствующей группы метрик.
270
Заключение
Представленная монография содержит результаты исследования, посвященного созданию формальной теории управления
качеством программных средств. Основными компонентами
теории являются модели программных средств, качества, измерений и преобразований программных средств, алгоритмы оценивания, преобразований и управления качеством программных
средств. Модель программных средств предоставляет базис для
описания характеристик программы, является основой для измерения этих характеристик, для квантификации архитектурных решений, для описания преобразований, описывает программу в независимом от предметной области, типа и парадигмы
разработки виде, содержит механизмы для адаптации с учетом
предметной области, типа и парадигмы. На модель качества возлагается задача описания концепции качества программных
средств, она является достаточной для фиксации однозначного
понимания понятия качества конкретного проекта для всех сторон, участвующих в разработке – заказчиков, пользователей и
разработчиков. Модель однозначно задает интерпретацию показателей качества, имеет инструменты для описания архитектурных решений. Модель качества предоставляет основу для последующего оценивания качества с помощью модели измерений.
Вместе с моделью измерений модель качества является источником информации о необходимых преобразованиях кода для
улучшения качества программы. Модель измерений является
основой для оценивания качества программы, она согласована с
моделью качества, разработан механизм формального отображения модели качества на модель измерений для поддержки процедуры оценивания качества. Модель преобразований основана
на модели программных средств и определяет инструментарий
для формального определения преобразований. Для формального предоставления информации о связи между программными
дефектами, которые помогают выявить модели качества и мероприятиями по улучшению качества модель измерений содержит
формальные механизмы для связывания метрик и преобразований, которые изменяют значения метрик. Алгоритм оценивания качества регламентирует использование моделей качества
и измерений, формально определяет этапы процесса оценивания
качества и их последовательность, с описанием входных и выходных данных каждого этапа. Алгоритм преобразований про271
граммных средств формально определяет порядок реализации
преобразований, которые описываются моделью преобразований
программных средств. Для формализации использования разработанных моделей при управлении качеством используется алгоритм управления качеством программных средств. Алгоритм
управления на основе моделей программных средств, качества,
измерений и преобразований формально задает все процессы
управления качеством и их взаимодействие.
Использование описанных в монографии моделей и алгоритмов делает возможным:
– описание понятия качества программных средств с варьируемой степенью детализации, от концепции – к измерениям
с целью нахождения компромисса между высоким качеством,
полнотой реализуемых функций, необходимых временных, денежных, людских и других ресурсов и создания консолидированного взгляда на качество программ с точки зрения заказчиков, разработчиков и пользователей;
– разработку шаблонов моделей качества и моделей измерений программ, для создания корпоративных, государственных и
мировых стандартов в области качества программ;
– разработку каталога качественных архитектурных решений, автоматизированный поиск компонент программы, которые нарушают правила использования шаблонов программирования, автоматизированную подготовку набора мероприятий по
исправлению ошибок в использовании шаблонов проектирования;
– формализацию процесса оценивания качества для создания
внутрикорпоративных, аудиторских и прочих стандартов определения качества программ;
– онлайновый мониторинг показателей качества для точного
управления процессом разработки программных средств;
– создание интеллектуальных систем, моделирующих действия эксперта путем классификации качественных состояний
программ в зависимости от значений метрик;
– формализацию процесса рефакторинга и иных видов преобразований для автоматизации процесса улучшения программных средств;
– разработку интеллектуальных систем, моделирующих действия эксперта по выбору видов преобразований программы для
улучшения ее качественного состояния;
272
– создание систем, автоматизирующих полный цикл процессов управления качеством программ: разработку модели качества и измерений, нахождение низкокачественных компонент,
выработку мероприятий по улучшению качества программы, отслеживание и оперативное реагирование на выходы показателей
качества за допустимые пределы на всех этапах разработки программных средств.
273
ЛИТЕРАТУРА
1. Липаев В. В. Выбор и оценивание характеристик качества
программных средств. М., 2001. 228 с.
2. Bell D., Morrey I., Pugh J. Software Engineering – A Programming Approach. N. J., 1987. 250 p.
3. Galin D. Software Quality Assurance: From Theory to
Implementation. Harlow, 2003. 616 p.
4. The Economic Impacts of Inadequate Infrastructure for
Software Testing. NIST Planning Report 02-3. Research Triangle
Institute, 2002. 309 p.
5. Йордон Э. Объектно-ориентированный анализ и проектирование систем. М., 2007. 264 с.
6. Pfleeger S. L. Software Engineering – Theory and Practice.
N. J., 2005. 736 p.
7. Goodman P. P. Software Metrics: Best Practices for Successful
IT Management. Rothstein Associates, 2004. 264 p.
8. Fenton N. E., Neil M. Software metrics: A Roadmap // ICSE –
Future of SE Track. 2000. P. 357–370.
9. Marinescu R. Measurement and Quality in Object-Oriented
Design // PhD thesis. Politehnica University of Timiseoara, 2002.
165 p.
10. ISO/IEC, ISO/IEC 25000: Software Engineering – Software
Product Quality Requirements and Evaluation (SQuaRE) – Guide to
SQuaRE. Geneva, 2005.
11. Cunningham W., Beck K. A Diagram for Object-Oriented
Programs // OOPSLA’86, ACM SIGPLAN Notices. 1986. № 21
(11). Р. 361–367.
12. Kleyn M. F., Gingrich P. C. GraphTrace – Understanding
Object-Oriented Systems Using Concurrently Animated Views //
OOPSLA’88, ACM SIGPLAN Notices. 1988. № 23 (11). Р. 191–
205.
13. Ellis G. Object-Oriented Conceptual Graphs // Proceedings
of the 3rd International Conference on Conceptual Structures.
Spinger-Verlag, 1995. Р. 144–157.
14. Chidamber S. R., Kemerer C. F. Towards a Metrics Suite for
Object-Oriented Design // OOPSLA’91, ACM SIGPLAN Notices.
1991. № 26 (11). Р. 197–211.
15. Meseguer J., Montanari U. Petri Nets are Monoids //
Information and Computation. 1990. № 88. Р. 105–155.
16. Bohner S. A., Arnold R. S. Software Change Impact Analysis.
IEEE Press, 1996. 262 p.
17. Ehrig H. et al. From Graph Grammars to High-Level
Replacement Systems // Proceedings of the 4th International
274
Workshop on Graph Grammars and their Application to Computer
Science. Springer-Verlag, 1991. P. 269–291.
18. Gruij D. A Framework of Concepts for Representing ObjectOriented Design and Design Patterns. Department of Computer
Science, Utrecht University INF/SCR-97-28, 1998. 120 p.
19. Mak J. K. H., Choy C. S. T., Lun D. P. K. Precise Modeling of
Design Patterns in UML // Proceedings of the 26th International
Conference on Software Engineering. 2004. P. 45–52.
20. Corradini A., Montanari U., Rossi F. Graph Processes //
Fundamenta Informaticae, Special Issue on Graph Transformations.
1996. № 26 (3, 4). Р. 241–265.
21. Corradini A. et al. The category of typed graph grammars
and their adjunction with categories of derivations // Proceedings
of the 5th International Workshop on Graph Grammars and their
Application to Computer Science. Springer-Verlag, 1996. P. 134–
140.
22. Heckel R. et al. Horizontal and Vertical Structuring of Typed
Graph Transformation Systems // Mathematical Structures in
Computer Science. Cambridge University Press, 1996. P. 211–219.
23. Corradini, A. et al. The Category of Typed Graph Grammars
and its Adjunction with Categories of Derivations // Graph
Grammars and Their Application to Computer Science. Springer
LNCS, 1996. P. 56–74.
24. Engels G., Schuеrr A. Encapsulated hierarchical graphs, graph
types and meta types // Electronic Notes in Theoretical Computer
Science. 1995. Vol. 2. P. 132–147.
25. Гамма Э. и др. Приемы объектно-ориентированного программирования. Паттерны проектирования. СПб., 2009. 368 c.
26. ISO/IEC 9126-1:2001. Software engineering – Software
product quality. Part 1: Quality model, 2001.
27. ISO/IEC 9126-2:2003 Software engineering – Product
quality. Part 2: External metrics, 2003.
28. ISO/IEC 9126-3:2003 Software engineering – Product
quality. Part 3: Internal metrics, 2003.
29. ISO/IEC 9126-4:2004 Software engineering – Product
quality. Part 4: Quality in use metrics, 2004.
30. Липаев В. В. Качество программных средств: метод. Рекомендации / под общ. ред. проф., д-ра техн. наук А. А. Полякова.
М., 2002. 400 с.
31. McCall J., Richards P., Walters G. Factors in Software
Quality. US Rome Air Development Center Reports NTIS AD-A049014, AD-A049-015, AD-A049-055, 1977.
32. Боэм Б. и др. Характеристики качества программного обеспечения. М., 1981. 208 с.
275
33. Boehm B. W. Software risk management. N. J., 1989. 495 р.
34. Grady R., Caswell D. Software metrics: establishing a
company-wide program. N. J., 1987. 288 p.
35. Gilb T. Principles of software engineering management.
Addison-Wesley, 1988. 464 p.
36. Keller S., Kahn L., Panara R. Specifying Software Quality
Requirements with Metrics // Systems and Software Requirements
Engineering. IEEE Computer Society Press, 1990. P. 145–163.
37. Wieringa R. Requirements Engineering: Problem Analysis
and Solution Specification. Berlin: Springer, 2004. 769 p.
38. Hyatt L. E., Rosenberg L. H. A Software Quality Model and
Metrics for Identifying Project Risks and Assessing Software
Quality // Product Assurance Symposium and Software Product
Assurance Workshop. Noordwijk, 1996. 209 p.
39. Bianchi A., Caivano D., Visaggio G. Quality Models Reuse:
Experimentation on Field // Proceedings of the 26th IEEE Computer
Software and Applications Conference. Oxford, 2002. Р. 535–540.
40. Dromey R. G. Cornering the Chimera // IEEE Software. 1996.
Vol. 20. P. 33–43.
41. Boegh J. et al. Method for Software Quality Planning, Control
and Evaluation // IEEE Software. 1999. Vol. 23. P. 69–77.
42. 1061-1998. IEEE Standard for Software Quality Metrics
Methodology, Software Engineering Standards Committee of the
IEEE Computer Society, USA, 1998.
43. ГОСТ 28195-89. Оценка качества программных средств.
Общие положения. М., 2001.
44. Azuma M. SQuaRE: The next Generation of ISO/IEC 9126
and 14598 International Standards Series on Software Product
Quality // Proceedings of the European Software Control and
Metrics Conference. London, 2001. P. 337–346.
45. ISO/IEC 15939. Software Engineering – Software
Measurement Process. Geneva: International Organization for
Standardization, 2002.
46. ISO/IEC. International Vocabulary of Basic and General
Terms in Metrology (VIM). Geneva, 1993.
47. Olsina L. Web-site Quality Evaluation Method: a Case Study
on Museums // ICSE 99–2 Workshop on Software Engineering over
the Internet. Los Angeles, 1999. P. 32–43.
48. Olsina L. et al. Quality Characteristics and Attributes for
Academic Web Sites // Web Engineering Workshop at WWW8.
Toronto, 1999. P. 67–73.
49. Bansiya J., Davis C. G. A Hierarchical Model for ObjectOriented Design Quality Assessment // IEEE Trans. Software Eng.
2002. № 28 (1). Р. 4–17.
276
50. Losavio F. et al. Quality Characteristics for Software
Architecture // Journal of Object Technology. 2003. № 2 (2).
Р. 133–150.
51. Simao R. P. S., Belchior A. D. Quality Characteristics
for Software Components: Hyerarchy and Quality Guides. //
Component-Based Software Quality: Methods and Techniques.
Heidelberg, 2003. Р. 184–206.
52. Fenton N. E., Pfleeger S. L. Software Metrics: A Rigorous and
Practical Approach. Boston, 1998. Р. 638.
53. Zuse H. A Framework of Software Measurement. Walter de
Gruyter & Co., 1997. 755 p.
54. Horgan G., Khaddaj S., Forte P. P. An essential views model
for software quality assurance // Project Control for Software
Quality / ed. R. Kusters et al. Shaker Publishing, 1999. P. 387–
396.
55. Dromey R. G. A Model for Software Product Quality // IEEE
Transactions on Software Engineering. 1995. P. 146–162.
56. Ghezzi C., Jazayeri M., Mandrioli D. Fundamentals of
software engineering. N. J., 2003. P. 563.
57. Wallmueller E. Software quality assurance: A quality
approach. Hertfordshire, 1994. P. 362.
58. Fitzpatrick R., Higgins C. Usable software and its attributes:
A synthesis of software quality // Proceedings of HCI’98 Conference.
London, 1998. P. 137–141.
59. Perry W. Effective methods for EDI quality assurance. N. J.,
1987. P. 279.
60. Chung L. et al. Non-Functional Requirements in Software
Engineering. Kluwer Aceademic Publishers, 1999. P. 472.
61. Tahvildari L. Quality-Driven Object-Oriented Re-engineering
Framework: PHD thesis. Ontario, 2003. 276 p.
62. Khaddaj S., Horgan G. Factors in Software Quality for
Advanced Computer Architectures // Proceedings of the ESCOM.
2001. P. 437–442.
63. Боэм Б. и др. Характеристики качества программного обеспечения. М., 1981. 208 с.
64. Меликян К. А., Хачатрян С. Т., Тер-Акопов А. К. О корректности алгоритмических процедур обработки экспертных
оценок качества программных средств // INFO-89. 1989. Т. 1.
Ч. 1. С. 622–624.
65. Дубенецкий В. А., Кузнецов А. Г., Рябов Ф. В. Проектирование функциональных спецификаций программ с использованием инструментального комплекса, построенного на основе
ЭВМ // INFO-89. 1989. Т. 1. Ч. 1. С. 397–401.
277
66. Firesmith D. G. Engineering Security Requirements //
Journal of Object Technology. 2003. № 2. Р. 53–68.
67. Klein M., Kazman R. Attribute-based architectural styles.
Pittsburgh, Technical Report, CMU/SEI-99-TR-022. Pittsburgh,
1999. 127 p.
68. Lundberg L. et al. Quality Attributes In Software Architecture
Design // Proceedings IASTED Third Int’l Conf. Software Eng. and
Applications. 1999. P. 353–362.
69. Kazman R., Klein M. ATAM: Method for Architecture
Evaluation. Technical Report, CMU/SEI-2000-TR-004, ESC-TR2000-004. Pittsburgh, 2000. 112 p.
70. Trendowicz A., Punter T. Quality Modeling for Software
Product Lines // Proceedings of 7th ECOOP Workshop on
Quantitative Approaches in Object-Oriented Software Engineering,
Darmstadt. 2003. P. 173–179.
71. Kontio J. A case study in applying a systematic method for
COTS selection // Proceedings of the 18th international conference
on Software engineering, IEEE Computer Society. 1996. P. 201–
209.
72. Yacoub S. et al. A Model for Certifying COTS Components
for Product Lines // Workshop on Continuing Collaborations
for Successful COTS Development, in conjunction with the 22nd
International Conference on Software Engineering (ICSE2000).
Limerick, 2000. P. 189–195.
73. Buglione L., Abran V. A Quality Factor for Software //
Proceedings
of
the
QUALITA99:
Third
International
Multidisciplinary Congress in Quality and Reliability. Paris, 1999.
P. 335–344.
74. Bertoa M. F., Troya J. M., Vallecillo A. A Survey on the
Quality Information Provided by Software Component Vendors //
Proceedings of the 7th ECOOP Workshop on Quantitative
Approaches in Object-Oriented Software Engineering (QAOOSE
2003). Darmstadt, 2003. P. 311–320.
75. Basili V. R. Software modeling and measurement. The GoalQuestion-Metric paradigm, Computer Science Technical Report.
UMIACS-TR-92-96. 1992. 131 p.
76. Briand L., Wuest J. Empirical Studies of Quality Models in
Object-Oriented Systems, Advances in Computers. 2002. № 56.
Р. 12–33.
77. Khoshgoftaar T. M., Allen E. B. Predicting fault-prone
software modules in embedded systems with classification trees //
Proceedings of the 4th IEEE International Symposium on HighAssurance Systems Engineering. 1999. Р. 173–179.
278
78. Tian J. Quality-evaluation models and measurements // IEEE
Software. 2004. № 21. Р. 84–91.
79. Maiden N., Ncube C. Acquiring COTS Software Selection
Requirements // IEEE Software. 1998. № 15 (2). Р. 46–56.
80. Цаленко M. Ш., Шульгейфер Е. Г. Основы теории категорий. М., 1974. 256 с.
81. Голдблатт Р. Топосы: категорный анализ логики. М.,
1983. 487 с.
82. Карпенко А. С. Логика на рубеже тысячелетий // Логические исследования. 2000. № 7. С. 7–60.
83. Григорьянц А. А. Тензорное и дифференциальное исчисление в категориях и их применение в теории дифференциальных
уравнений в частных производных: дис. … канд. физ.-мат. наук.
Ереван, 1999. 64 с.
84. Фаулер М. Архитектура корпоративных программных
приложений / пер. с англ. М., 2006. 544 с.
85. Abran A., Sellami A. Initial Modeling of the Measurement
Concepts in the ISO Vocabulary of Terms in Metrology // Proceedings
of the 10th International Workshop on Software Technology and
Engineering Practice. 2002. P. 185–192.
86. ISO/IEC 14598-1:1999. Information Technology – Software
Product Evaluation. Part 1: General Overview. Geneva, 1999.
87. ISO/IEC 14598-2:2000. Software Engineering – Product
Evaluation. Part 2: Planning and Management. Geneva, 2000.
88. ISO/IEC 14598-3:2000. Software Engineering – Product
Evaluation. Part 3: Process for Developers. Geneva, 2000.
89. ISO/IEC 14598-4:1999. Software Engineering – Product
Evaluation. Part 4: Process for Acquirers. Geneva, 1999.
90. ISO/IEC 14598-5:1998. Information Technology – Software
Product Evaluation. Part 5: Process for Evaluators. Geneva, 1998.
91. ISO/IEC 14598-6:2001. Software Engineering – Product
Evaluation. Part 6: Documentation of Evaluation Modules. Geneva,
2001.
92. Abran A. et al. An Information Model for Software Quality
Measurement with ISO Standards // Proceedings of the International
Conference on Software Development (SWDC-REK). 2005. P. 104–
116.
93. Фаулер М. Рефакторинг: улучшение существующего кода.
М., 2008. С. 432.
94. Briand L. C., Bunse C., Daly J. W. A Controlled Experiment
for Evaluating Quality Guidelines on the Maintainability of ObjectOriented Designs // IEEE Transactions on Software Engineering.
2001. № 27 (6). Р. 513–530.
279
95. Briand L. C. et al. An Experimental Comparison of the
Maintainability of Object-Oriented and Structured Design
Documents // Empirical Software Engineering. An International
Journal. 1997. № 2 (3). Р. 291–312.
96. Abreu F. B., Melo W. Evaluating the Impact of ObjectOriented Design on Software quality // Proceedings of Symposium
on Software Metrics METRICS ’96. 1996. Р. 90–99.
97. Johnson R. E., Foote B. Designing reuseable classes // Journal
of Object-Oriented Programming. 1988. № 1 (2). Р. 22–35.
98. Riel A. J. Object-Oriented Design Heuristics. Addison-Wesley
Professional, 1996. 400 p.
99. Мейер Б. Объектно-ориентированное конструирование
программных систем. М., 2005. 1232 с.
100. Martin R. C. Design Principles and Patterns. Object Mentor,
2000. 34 p.
101. Liskov B. Data Abstraction and Hierarchy. ACM SIGPLAN
Notices. 1988. № 23 (5). Р. 300–312.
102. Meyer B. Tools for a new culture – Lessons from the design
of the Eiffel libraries // Communications of the ACM. 1990. Vol. 33.
№ 9. Р. 40–60.
103. Lieberherr K. J., Holland I. M. Assuring good style for
objectoriented programming // IEEE Software. 1989. Р. 38–48.
104. Brown W. J. et al. AntiPatterns: Refactoring Software,
Architectures, and Projects in Crisis. John Wiley and Sons, 1998.
156 p.
105. Бураков В. В., Устюхин Н. В., Ковригин Д. А. Применение
телемедицинских технологий в медицинской службе Вооруженных Сил Российской Федерации // Медицина и высокие технологии. 2006. № 1. С. 73–79.
106. Ehrig H., Pfender M., Schneider H. J. Graph grammars:
an algebraic approach // Proceedings of the 14th Annual IEEE
Symposium on Switching and Automata Theory. 1973. Р. 167–
180.
107. Corradini A. et al. Algebraic Approaches to Graph
Transformation I Basic Concepts and Double Pushout Approach.
Handbook of Graph Grammars and Computing by Graph
Transformation / eds. by G. Rozenberg. World Scientific Publishing,
1997. P. 289–328.
108. Corradini A. et al. Algebraic approaches to graph
transformation part II. Single pushout approach and comparison
with double pushout approach. Handbook of Graph Grammars and
Computing by Graph Transformation / eds. by G. Rozenberg. World
Scientific Publishing, 1997. P. 331–386.
280
109. Kreowski H. J., Kuske S. On the interleaving semantics of
transformation units – a step into GRACE // Proceedings of the
5th Int. Workshop on Graph Grammars and their Application to
Computer Science. Wiliamsburg, 1994. P. 89–106.
110. Ehrig H., Engels G. Pragmatic and semantic aspects of a
module concept for graph transformation systems // Proceedings
of the 5th Int. Workshop on Graph Grammars and their Application
to Computer Science. Wiliamsburg, 1994. P. 137–154.
111. Taentzer G., Schuerr A. DIEGO, another step towards a
module concept for graph transformation systems // Proceedings of
SEGRAGRA Graph Rewriting and Computation, Electronic Notes
of TCS. 1995. № 2. Р. 121–128.
112. Parisi-Presicce F. Transformation of graph grammars //
Proceedings of the 5th International Workshop on Graph Grammars
1994 / eds. by J. Cuny et al. Springer-Verlag, 1996. P. 428–442.
113. Heckel R. et al. Horizontal and vertical structuring of
typed graph transformation systems // Mathematical Structures in
Computer Science. 1996. № 6. Р. 613–648.
114. Pfaltz J. L., Rozenfeld A. Web Grammars // Proceedings
of International Joint Conference on Artificial Intelligence.
Washington, 1969. Р. 609–619.
115. Montanari U. G. Separable Graphs, Planar Graphs and Web
Grammars // Proceedings of the Inf. Contr. 1970. № 16. Р. 243–
267.
116. Ehrig H., Habel A. Graph grammars with application
conditions / eds. by G. Rozenberg, A. Salomaa. Springer-Verlag,
1986. P. 87–100.
117. Habel A., Heckel R., Taentzer G. Graph grammars with
negative application conditions // Fundamenta Informaticae. 1996.
№ 26. Р. 287–313.
118. Heckel R., Wagner A. Ensuring Consistency of Conditional
Graph Grammars – A Constructive Approach. Lecture Notes in
Theoretical Computer Science 1. Elsevier Science, 1995. Р. 314–
342.
119. Heckel R. Algebraic Graph Transformations with Application
Conditions: dissertation. Berlin, 1995. 178 p.
120. Ehrig H. Introduction to the algebraic theory of graph
grammars // Graph-Grammars and Their Application to Computer
Science and Biology. Lecture Notes in Computer Science. 1979.
Vol. 73. P. 1–69.
121. Lowe M. Algebraic Approach to Single-Pushout Graph
Transformation // Theoretical Computer Science. 1993. № 109.
Р. 181–224.
281
122. Ehrig H. et al. From Graph Grammars to High-Level
Replacement Systems // Proceedings of the 4th International
Workshop on Graph Grammars and their Application to Computer
Science. 1991. P. 269–291.
123. Schurr A. PROGRES for Beginners. Department of Computer
Science. Aachen University of Technology. 1997. 215 p.
124. Loewe M. Extended Algebraic Graph Transformations: PhD
thesis // Technical University of Berlin, short version in TCS. 1990.
№ 109. Р. 181–224.
125. Schurr A. Logic Based Programmed Structure Rewriting
Systems // Fundamenta Informaticae, Special Issue on Graph
Transformations. 1996. № 26 (3,4). Р. 363–385.
126. Korff M. Minimality of derived rules in single pushout
graph rewriting // Technical Report. 1994. № 94 (10). 132 p.
127. Ehrig H., Rosen B. K. Parallelism and concurrency of graph
manipulations // Theoretical Computer Science. 1980. № 11.
Р. 247–275,
128. Taentzer G. Towards synchronous and asynchronous graph
transformations // Special issue of Fundamenta Informaticae.
1996. Vol. 26. P. 145–167.
129. Lucas C. Documenting Reuse and Evolution with Reuse
Contracts: dissertation. Brussel, 1997. 216 p.
130. Steyaert P. P. et al. Reuse Contracts:Managing the Evolution
of Reusable Assets // Proceedings of OOPSLA ’96. 1996. № 31 (10).
Р. 268–286.
131. Hondt K. D. A Novel Approach to Architectural Recovery
in Evolving Object-Oriented Systems: dissertation. Brussel, 1998.
187 p.
132. Janssens D., Mens T. Abstract semantics for ESM systems //
Fundamenta Informaticae. 1996. P. 315–339.
133. Ehrig H., Loewe M. Parallel and distributed derivations
in the single-pushout approach // Theoretical Computer Science.
1993. P. 123–143.
134. Loewe M. Algebraic approach to single-pushout graph
transformation // Theoretical Computer Science. 1993. P. 181–
224.
135. Opdyke W. F., Johnson R. E. Creating abstract superclasses
by refactoring // Proceedings of 1993 ACM Computer Science
Conference. ACM Press, 1993. P. 66–73.
136. Opdyke W. F. Refactoring object-oriented frameworks:
dissertation. Illinois, 1992. 142 p.
137. Tokuda L., Batory D. Evolving Object-Oriented Architectures
with Refactorings // Technical Report. 1999. 123 p.
282
138. Werner M. M. Facilitating Schema Evolution With
Automatic Program Transformations: dissertation. College of
Computer Science of Northeastern University, 1999. 156 p.
139. Барабаш Ю. Л. и др. Вопросы статистической теории распознавания / под ред. Б. В. Варского. М., 1967. 400 с.
140. Васильев В. И. Распознающие системы: справочник.
Киев, 1983. 230 с.
141. Горелик А. Л., Скрипкин В. А. Методы распознавания. 2-е
изд. М., 1984. 219 с.
142. Дуда Р., Харт П. Распознавание образов и анализ сцен /
пер. с англ. М., 1978. 510 с.
143. Кузин Л. Т. Основы кибернетики. Основы кибернетических моделей. Т. 2. М., 1979. 584 с.
144. Перегудов Ф. И., Тарасенко Ф. П. Введение в системный
анализ. М., 1989. 367 с.
145. Темников Ф. Е. и др. Теоретические основы информационной техники. М., 1979. 511 с.
146. Витюк Н. Г., Николаев А. Ю. Комплексная автоматизация военной медицины // Компьютер-Информ. 2001. № 16.
С. 4–5.
147. Базикмед прошел Госиспытания // Компьютер-Ин-форм.
2005. № 9. С. 2.
148. Бураков В. В. Программное средство анализа кода для рефакторинга. Свидетельство об отраслевой регистрации разработки № 10143; номер гос. регистр. 50200800552. М., 2008.
149. Бураков В. В. Программное средство автоматизации пользовательского рефакторинга. Свидетельство об отраслевой регистрации разработки № 10144; номер гос. регистр. 50200800553.
М., 2008.
150. Бураков В. В. Программное средство детектирования дефектов кода. Свидетельство об отраслевой регистрации разработки № 10145; номер гос. регистр. 50200800554. М., 2008.
151. Бураков В. В. Программное средство метрического анализа кода. Свидетельство об отраслевой регистрации разработки
№ 10146; номер гос. регистр. 50200800555. М., 2008.
152. Бураков В. В. Программное средство оценки качества
программ. Свидетельство об отраслевой регистрации разработки
№ 10147; номер гос. регистр. 50200800556. М., 2008.
153. Бураков В. В. Программное средство рефакторинга моделей программ. Свидетельство об отраслевой регистрации разработки № 10148; номер гос. регистр. 50200800557. М., 2008.
283
Содержание
Введение......................................................................
Глава 1. Моделирование программных средств..................
1.1. Графовая модель программы...................................
1.1.1. Расширение базовой теории графов.....................
1.1.2. Понятие помеченного графа...............................
1.1.3. Понятие помеченного типизированного графа.......
1.1.4. Визуализация помеченных типизированных
графов......................................................................
1.1.5. Абстрактный помеченный граф...........................
1.1.6. Понятие подграфа.............................................
1.1.7. Принципы типизации........................................
1.1.8. Частично-упорядоченные графовые типы.............
1.1.9. Морфизмы, сохраняющие подтипы.....................
1.1.10. Спецификация множественности......................
1.2. Адаптация графовой модели к предметной области....
1.3. Моделирование диаграмм классов UML....................
1.3.1. Идентификация типов вершин и ребер.................
1.3.2. Построение множества типовых графов................
1.3.3. Построение множества антитиповых графов.........
1.4. Моделирование объектно-ориентированного кода......
1.4.1. Идентификация типов вершин и ребер.................
1.4.2. Построение множества типовых графов................
1.4.3. Построение множества антитиповых графов.........
1.5. Описание принципов проектирования с помощью
антитиповых графов....................................................
1.6. Описание принципов проектирования с помощью
ролей.........................................................................
1.6.1. Варианты описания ролей в программном коде.....
1.6.2. Порождающий шаблон «абстрактная фабрика».....
1.6.3. Структурный шаблон «мост»..............................
1.6.4. Поведенческий шаблон «наблюдатель»................
1.6.5. Архитектурный шаблон «модель – представление –
контроллер».............................................................
Глава 2. Моделирование качества программных средств.....
2.1. Существующие модели и стандарты качества ПС.......
2.1.1. Модели типа «факторы – критерии – метрики».....
2.1.2. Модели типа «цель – вопрос – метрика»...............
2.1.3. Модели типа «процесс/продукт».........................
2.1.4. Стандарт IEEE 1061...........................................
2.1.5. ГОСТ 28195-89..................................................
284
3
10
11
14
14
16
17
18
19
20
21
21
22
22
23
23
24
25
25
26
29
29
31
32
32
33
34
37
38
42
43
44
48
50
52
53
2.1.6. Стандарты ISO/IEC 9126, ISO/IEC 25000.............. 56
2.1.7. Сравнительный анализ существующих моделей
качества................................................................... 61
2.2. Построение моделей качества.................................. 64
2.2.1. Жесткие и гибкие модели................................... 64
2.2.2. Модели с совмещениями уровней и без................. 65
2.2.3. Внутренние и внешние свойства качества............. 66
2.3. Взаимосвязи между показателями качества.............. 66
2.3.1. Методы построения моделей качества.................. 68
2.3.2. Анализ вариантов построения моделей качества.... 69
2.4. Адаптация моделей качества.................................. 71
2.5. Области применения моделей качества..................... 72
2.5.1. Использование моделей качества для описания
требований к ПС........................................................ 72
2.5.2. Использование моделей качества для проектирования архитектуры ПС............................................... 73
2.5.3. Использование моделей качества для реализации
ПС........................................................................... 74
2.5.4. Использование моделей качества при приобретении ПС..................................................................... 75
2.5.5. Использование моделей качества при сертификации ПС..................................................................... 76
2.5.6. Использование моделей качества при идентификации рисков............................................................... 76
2.5.7. Другие применения моделей качества ПС............. 76
2.5.8. Анализ вариантов использования моделей качества......................................................................... 77
2.6. Классификация моделей качества........................... 77
2.6.1. Специфичное/обобщенное измерение................... 79
2.6.2. Устойчивое/временное измерение....................... 80
2.7. Основные недостатки существующих моделей качества........................................................................... 81
2.8. Требования к модели качества................................. 83
2.9. Формальная модель качества.................................. 84
2.9.1. Категория качества........................................... 93
2.9.2. Реализация требований формального моделирования качества.......................................................... 99
Глава 3. Оценивание качества программных средств.......... 105
3.1. Модель измерений программных средств.................. 105
3.1.1. Измерение качества программных средств............ 105
285
3.1.2. Метрики качества программных средств..............
3.1.3. Метрические пространства.................................
3.1.4. Операторы комплексирования............................
3.1.5. Категория измерений........................................
3.1.6. Функтор из категории качества в категорию измерений.......................................................................
3.1.7. Квантификация принципов проектирования
программных средств.................................................
3.2. Алгоритм оценивания качества программных
средств.......................................................................
3.2.1. Стандарты оценивания качества программных
средств.....................................................................
3.2.2. Процесс оценивания качества программных
средств.....................................................................
Глава 4. Улучшение качества программных средств...........
4.1. Модель преобразований программных средств...........
4.1.1. Преобразования графов.....................................
4.1.2. Формальное описание преобразований программных средств............................................................
4.1.3. Операторы преобразований на метрических пространствах................................................................
4.1.4. Моделирование преобразований ОО-кода..............
4.1.5. Преобразования диаграмм классов UML...............
4.2. Алгоритм преобразований программных средств.......
4.2.1. Поиск сущностей дефектных подпространств........
4.2.2. Поиск оптимальной последовательности операторов...........................................................................
4.2.3. Нормализация составных преобразований............
4.2.4. Алгоритм нормализации составных преобразований..........................................................................
Глава 5. Управление качеством программных средств........
5.1. Структура системы управления качеством программных средств..............................................................
5.2. Описание элементов системы управления качеством
программных средств...................................................
5.3. Применение методов классификации и кластерного
анализа......................................................................
5.3.1. Сравнительный анализ методов классификации....
5.3.2. Применение методов кластерного анализа............
5.4. Алгоритм функционирования системы управления
качеством программных средств....................................
286
121
124
127
128
132
134
142
142
151
162
162
162
183
195
196
202
210
211
211
214
215
220
220
220
222
223
231
233
Глава 6. Программное обеспечение для управления качеством...........................................................................
6.1. Программное средство анализа кода для рефакторинга.........................................................................
6.1.1. Функциональное назначение..............................
6.1.2. Результаты использования.................................
6.2. Программное средство автоматизации пользовательского рефакторинга.....................................................
6.2.1. Функциональное назначение..............................
6.2.2. Результаты использования.................................
6.3. Программное средство детектирования дефектов
кода..........................................................................
6.3.1. Функциональное назначение..............................
6.3.2. Результаты использования.................................
6.4. Программное средство метрического анализа кода.....
6.4.1. Функциональное назначение..............................
6.4.2. Метрики, реализованные в ПСМАК.....................
6.4.3. Функции, выполняемые ПСМАК........................
6.4.4. Результаты использования.................................
6.5. Программное средство оценки качества программ....
6.5.1. Функциональное назначение..............................
6.5.2. Функции ПСОКП..............................................
6.5.3. Результаты использования.................................
6.6. Программное средство рефакторинга моделей программ........................................................................
6.6.1. Функциональное назначение..............................
6.6.2. Результаты использования.................................
6.7. Результаты практического использования разработанных программных средств .......................................
Заключение.................................................................
Литература..................................................................
240
243
243
244
244
245
250
251
251
253
254
254
255
258
259
259
259
262
262
264
264
267
267
271
274
287
Научное издание
Бураков Вадим Витальевич
УПРАВЛЕНИЕ КАЧЕСТВОМ
ПРОГРАММНЫХ СРЕДСТВ
Монография
Редактор В. А. Черникова
Верстальщик С. Б. Мацапура
Дизайн обложки К. В. Дьяченко
Сдано в набор 10.02.09. Подписано к печати 15.04.09.
Формат 60×84 1/16. Бумага офсетная. Печать офсетная. Печ. л. 18,0.
Уч.-изд. л. 17,5. Тираж 1000 экз. Заказ № 287.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
Документ
Категория
Без категории
Просмотров
13
Размер файла
8 267 Кб
Теги
bur
1/--страниц
Пожаловаться на содержимое документа