Различное программное обеспечение используется на

На правах рукописи
Бураков Вадим Витальевич
МОДЕЛИ ОЦЕНИВАНИЯ И АЛГОРИТМЫ УПРАВЛЕНИЯ КАЧЕСТВОМ
ПРОГРАММНЫХ СРЕДСТВ
Специальность 05.13.11 – «Математическое и программное обеспечение
вычислительных машин, комплексов и компьютерных сетей»
АВТОРЕФЕРАТ
диссертации на соискание ученой степени
доктора технических наук
Санкт-Петербург
2010
Работа
выполнена
на
кафедре компьютерной математики и
программирования Государственного образовательного учреждения высшего
профессионального образования «Санкт-Петербургский государственный
университет аэрокосмического приборостроения»
Научный консультант:
Заслуженный деятель науки РФ,
доктор технических наук, профессор
Хименко Виталий Иванович
Официальные оппоненты:
Заслуженный деятель науки РФ,
доктор технических наук, профессор
Рыжиков Юрий Иванович
доктор технических наук, профессор
Хомоненко Анатолий Дмитриевич
доктор технических наук, профессор
Шейнин Юрий Евгеньевич
Ведущая организация:
Санкт-Петербургский институт информатики и автоматизации Российской
академии наук
Защита состоится «__» ___________ 2010 г. в __:__ часов на заседании
диссертационного совета Д 212.233.02 при Государственном образовательном
учреждении высшего профессионального образования «Санкт-Петербургский
государственный университет аэрокосмического приборостроения» по адресу
190000, Санкт-Петербург, ул. Большая Морская, д. 67.
С диссертацией можно ознакомиться в библиотеке Санкт-Петербургского
государственного университета аэрокосмического приборостроения.
Автореферат разослан «__» ___________ 2010 г.
Ученый секретарь
диссертационного совета
доктор технических наук, профессор
Осипов Л.А.
2
ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ
Компьютерные технологии и программное обеспечение используются на
современной стадии развития общества повсеместно. Практически все виды
человеческой деятельности, включая потенциально опасные для жизни людей и
планеты, доверены компьютерному управлению. В разработку программных
средств вовлечено множество людей и организаций, на создание программ
расходуются огромные ресурсы. Учитывая эти факты, нет необходимости в
доказательстве актуальности и практической значимости исследований в области
качества программного обеспечения. В этой области особенно важными
представляются проблема формирования общих подходов к оцениванию качества
и задача определения общих принципов управления качеством программных
средств.
Оценивание
качества
программного
обеспечения
является
многокритериальным процессом, который объединяет такие действия, как
формирование набора критериев, выбор их эталонных значений, измерение
фактических значений, сравнение их с эталонными и определение состояния
качества программы. В современной практике разработки программ все
составляющие процесса оценивания реализуются экспертами, а сформированная в
результате оценка качества не всегда является объективной. Выбранные для
оценивания критерии носят, в основном, описательный характер, процедура
выбора эталонных значений – интуитивная, процессы измерения и сравнения –
трудно формализуемые. Для управления процессом разработки программы
необходимо осуществлять оценку ее качественного состояния постоянно, набор
критериев для оценивания и их эталонные значения должны изменяться
сообразно с прогрессом, достигаемым в разработке. В расчете на одну
экспертную оценку трудно обеспечить адаптацию процесса оценивания в
соответствии с состоянием разработки непротиворечивым, верифицируемым
способом. Существующие стандарты и исследования в области оценивания
качества не обеспечивают нужной степени формализации, описывают процессы,
связанные с оцениванием качества или в абстрактном, непригодном для
непосредственного применения, или в детальном, плохо поддающимся адаптации
под конкретные реалии разработки, стиле. Неопределенности и пробелы в
формализации качества программ провоцируют субъективность при оценивании
их качества экспертами, позволяют вводить в эксплуатацию низкокачественные
программные продукты, использование которых может быть экономически
невыгодным и зачастую небезопасным. Высокая сложность и ответственность
задач, решаемых программами, возможный материальный ущерб и угрозы для
жизни людей как следствие их недостаточного качества, делают необходимым
формализацию всех составляющих процесса оценивания.
При выявлении несоответствия значений измеренных и эталонных
показателей в результате процесса оценивания, необходимо определить
корректные изменения структурных и поведенческих свойств программы,
которые бы позволили перевести ее из одного качественного состояния в другое.
Выявленные рассогласования значений измеренных и эталонных показателей
являются симптомами наличия проблем в структуре и поведении программы. Для
3
того чтобы на основе этой, симптоматической информации можно было бы
принять определенные решения о доработке программы, она должна быть
правильно интерпретирована. При решении этой многокритериальной задачи
важно гарантировать отсутствие побочного эффекта, который состоит в
ухудшении значений одних показателей качества в процессе улучшения других.
Эта задача, также как и проблема оценивания качества программы, в современной
практике разработки программ в основном решается экспертами. Существующие
стандарты и исследования проблем качества программного обеспечения не
определяют способы использования результатов оценивания. Необходима
разработка формализованных моделей связывания качественного состояния
программы с подходами к его изменению, строгое описание критериев
оптимизации и определение общих принципов управления качеством программ.
Важность задач, решаемых программными средствами и описанные пробелы
в современном состоянии программной инженерии, выявляют настоятельную
потребность в проведении исследований, направленных на разработку
математических моделей, методов и алгоритмов для формализации процессов
оценивания и управления качеством программ. Решение проблемы обеспечения
процессов оценивания и управления качеством строгим математическим
аппаратом позволит повысить эффективность процессов обработки данных и
знаний в вычислительных машинах, комплексах и компьютерных сетях и
сократить сроки их создания.
Цель диссертационной работы состоит в разработке обобщенных моделей
для оценивания качества программ и формировании общих принципов
управления качеством на этапах создания программных средств.
Основные задачи. Для достижения поставленной цели в диссертационной
работе решались следующие основные задачи.
1.
Разработка структуры и методов адаптации обобщенной модели
программных средств к задаче управления качеством.
2.
Систематизация и обобщение основных подходов к описанию качества
программных средств.
3.
Разработка структуры и методов формализованного описания качества
программных средств.
4.
Исследование наиболее распространенных принципов оценивания
качества программных средств.
5.
Создание обобщенных принципов оценки качественных состояний
программ.
6.
Анализ и систематизация существующих подходов к оптимизации
структурных и поведенческих свойств программных средств.
7.
Разработка общих принципов управления качеством на основных этапах
жизненного цикла программных средств.
Методы исследования. При выполнении диссертационных исследований
использовались: общие методы системного анализа, общие методы теории
программирования, методы теории автоматического управления, методы
математического моделирования, методы функционального анализа, методы
теории оптимизации.
4
Научная новизна выполненных исследований заключается в следующем:
1.
Реализован системный подход к исследованию принципов оценивания и
управления качеством программных средств.
2.
Предложены формализованные основы моделирования программ,
отвечающие задачам определения и изменения их качества.
3.
Сформированы основные принципы описания качества программ и
предложен метод формализованного описания качества.
4.
Выработаны
методы
оценивания
и
предложена
процедура
автоматизированной оценки качества программных средств.
5.
Систематизированы принципы оптимизации качественных состояний
программных средств.
6.
Определены
обобщенные
принципы
управления
качеством,
предназначенные для использования на этапах создания программных
средств.
Практическая значимость. Выполненные в диссертационной работе
исследования обеспечивают основу для создания и развития перспективных
автоматизированных систем оценивания и управления качеством программ.
Предлагаемые в работе модели, методы и алгоритмы позволяют:
 создавать формализованные описания качества программных средств с
варьируемой степенью детализации, от концепции – к измерениям с целью
итерационного нахождения компромисса между высоким качеством, полнотой
реализуемых функций, необходимых временных, денежных, людских и других
ресурсов и создания консолидированного взгляда на качество программ с
точки зрения заказчиков, разработчиков и пользователей;
 формировать каталоги шаблонов формализованных описаний качества и
моделей измерений программ, для создания корпоративных, государственных
и международных стандартов в области качества программных средств;
 разрабатывать каталоги высоко- и низкокачественных архитектурных и
проектных программных решений, осуществлять автоматизированную
классификацию компонент программы по качественным состояниям;
 автоматизировать подготовку и реализацию процессов перевода программного
средства из одного качественное состояние в другое;
 разрабатывать программные системы онлайнового контроля качественного
состояния программных средств на всех этапах их создания;
 создавать информационно-управляющие системы автоматизации полного
цикла процессов управления качеством программ.
В целом, выполненные в диссертации исследования и разработанные
теоретические положения могут квалифицироваться как новое крупное
достижение в решении проблем оценивания и управления качеством
программных средств.
Основные положения, выносимые на защиту:
1. Многоцелевая математическая модель программных средств и способы ее
адаптации к задаче управления качеством.
2. Метод формализованного описания качества программных средств.
5
3. Математическая модель измерений качества программных средств, метод ее
синтеза и алгоритм оценивания качества программных средств.
4. Метод оценки степени соответствия программного средства типовым
программным решениям.
5. Математическая модель и алгоритм оптимизации качества программных
средств.
6. Общие принципы и алгоритм управления качеством на этапах создания
программных средств.
Внедрение
результатов.
Результаты
диссертационной
работы
использовались при разработке процедур управления проектами и подходов к
созданию программ, создании стандартов качества предприятия и разработке
специального программного обеспечения для Министерства Обороны Российской
Федерации:

в ходе опытно-конструкторской работы шифр «Базикмед» (Государственный
контракт от 30.12.98 № НТК/2/6-1998);

в ходе опытно-конструкторской работы шифр «Телемед» (Государственный
контракт от 27.04.02 № ВНК/1/3-2002);

в ходе опытно-конструкторской работы шифр «Кладезь» (Государственный
контракт от 27.10.04 № ВНК/7/24-2004);

в
ходе
опытно-конструкторской
работы
шифр
«Автография»
(Государственный контракт от 30.03.06 № 5921).
Кроме того, полученные в диссертационной работе результаты внедрены в
учебный процесс Санкт-Петербургского государственного университета
аэрокосмического приборостроения (на кафедре компьютерной математики и
программирования) по направлению «Информатика и вычислительная техника»
при разработке курсов «Объектно-ориентированное программирование»,
«Технология разработки программного обеспечения», «Стандарты и технологии
распределенных объектных архитектур».
Апробация работы. Основные результаты работы докладывались и
обсуждались на конференциях и семинарах: на Международной конференции
«Интеллектуальные многопроцессорные системы – ИМС-99» (г. Таганрог, 1999
г.); Пятой Международной конференции «Распознавание образов и анализ
изображений – РОАИ-5-2000» (г. Самара, 2000 г.); Всероссийской НТК «Методы
и средства обработки информации» (г. Москва, 2002 г.); на XVII Всероссийском
семинаре «Передача, обработка, отображение информации» (г. Ставрополь, 2006
г.); на XV и XVII Международном научно-техническом семинаре «Современные
технологии в задачах управления, автоматики и обработки информации» (г.
Алушта, 2006 и 2008 гг.); на Международном научно-техническом семинаре
«Информационные, измерительные и управляющие системы» (г. Самара, 2005 г.);
Международном форуме «Информационно-коммуникационные технологии» (г.
Санкт-Петербург, 2008 г.); на ежегодных Научных сессиях Государственного
университета аэрокосмического приборостроения (г. Санкт-Петербург, 2005 –
2009 г.г.).
Публикации. По результатам диссертационных исследований опубликована
монография, 33 научные статьи, из которых 18 опубликовано в ведущих
6
рецензируемых научных журналах, входящих в Перечень изданий,
рекомендуемых
ВАК,
получено
6
свидетельств
на
разработки,
зарегистрированные в Отраслевом фонде алгоритмов и программ.
Структура диссертации. Диссертация состоит из введения, семи глав,
заключения, списка использованных источников и двух приложений. Основной
материал диссертации изложен на 279 страницах машинописного текста,
содержит 98 рисунков и 44 таблицы. Библиографический список включает 220
наименований.
СОДЕРЖАНИЕ ДИССЕРТАЦИИ
Во введении обоснована актуальность, определена цель и основные задачи
диссертационного исследования, сформулированы положения, выносимые на
защиту, описано содержание диссертации по главам.
Первая глава посвящена описанию подхода к моделированию программных
средств, которые находятся на одном из этапов своего создания и представляют
собой проектные модели или исходные коды. Модель программы является
основой для реализации формализованных подходов к оцениванию и управлению
качеством. К модели были предъявлены следующие требования: обобщенный
характер
технологии
программирования
постоянно
развиваются,
разрабатываемые подходы не должны зависеть от конкретных языков
программирования и способов их использования, варьируемая степень
детализации – при оценке и управлении качеством не всегда необходимо
моделировать все структурные и поведенческие свойства программы, необходима
модель, обладающая возможностью выбора степени детальности отображения
реального объекта. Наконец, модель программы является основой для измерения
качества и поэтому должна обеспечивать адекватную возможность обсчета своих
составляющих. Для обеспечения выполнения этих требований для моделирования
программ используются графы. Варьируемая детальность, наглядность и простота
представления программных сущностей и взаимоотношений между ними
сочетается в графовых спецификациях с развитым математическим базисом. С
целью обеспечить необходимый математический аппарат для решения общей
задачи оценки и управления качеством, базовое понятие графа было дополнено
рядом надстроек, в результате которых полученная многоцелевая математическая
модель программного средства получила ряд уникальных особенностей. Одной из
главных таких особенностей следует считать возможность моделирования
программного средства с той степенью детализации, которая необходима для
решения задач оценивания и управления качеством, а также простоту адаптации
модели к изменяющимся целям моделирования. Другой особенностью модели
является ее направленность на описание типовых программных решений и
программной архитектуры. Модель снабжена специальными механизмами,
позволяющими наглядно и относительно просто описывать ограничения на
структурные и поведенческие свойства программ. Наконец, для разработанной
модели характерна общая проработка с точки зрения потребностей других
компонентов системы управления качеством – моделей измерений и
7
преобразований, служащих соответственно для оценивания и оптимизации
качества программного средства.
Многоцелевая математическая модель программного средства предназначена
для описания проектных моделей и исходного кода, которые, в свою очередь,
также являются моделями программы. Поэтому разработанная модель
программного средства является метамоделью, но для простоты изложения
называется в работе моделью.
В начале главы формулируются определения понятий, положенных в основу
модели программных средств.
Ориентированный граф G = (V,E,s,t) состоит из двух множеств, конечного
множества V, элементы которого называются вершинами, и конечного множества
E, элементы которого называются ребрами. Каждое ребро связано с
упорядоченной парой вершин. Функции s: E V и t: E V связывают с каждым
ребром в точности одну начальную и одну конечную вершины.
Для двух графов, G и H графовый морфизм f:G H представляет собой пару
функций (fv:VGVH, fe:EGEH) такую, что выполняется fvsG = sH fe и fv tG
= tH fe. Категория графов, содержащая в качестве объектов графы, а в качестве
морфизмов графовые гомоморфизмы обозначается Graph.
Далее в первой главе формулируются понятия графовых изоморфизмов,
инъективных и сюръективных морфизмов, частичных и тотальных графовых
морфизмов. В качестве расширений к базовой структуре графа, описанного выше,
используются метки, роли, порядок и типы. Метки служат для именования
элементов модели, роли - с целью спецификации контекста использования
моделируемой программной сущности, порядок служит целям моделирования
поведения, типизация используется для классификации вершин и ребер.
В продолжении главы приводятся определения конструкций расширения,
используемых в модели программных средств. Пусть 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) - функция отображения вершин на множество
ролей.
Упорядоченный граф G представляет собой (L,A) -помеченный граф, в
котором ребра, выходящие из каждой вершины v  VG, упорядочены, помечены
номерами 1,…, kv, где kv – число ребер, исходящих из вершины v, то есть kv =
|{w: (v,w)  EG}|. Упорядоченные графы используются для моделирования не
только структурных, но и поведенческих свойств программы, так как могут
задавать порядок выполнения операторов исходного кода программы, порядок
следования действий на диаграмме деятельности UML и т.п.
Добавление к формализму помеченного графа механизма, связывающего с
каждым ребром и вершиной понятие типа, служит целям классификации, которая
позволяет выявить сходные свойства вершин или ребер, тем самым, упрощая
8
представление графа. Пусть 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.
Пусть G и H – (L,A)-помеченные T-типизированные графы. f:GH
представляет собой помеченный типизированный графовый морфизм, если f
является помеченным графовым морфизмом между (L,A)-помеченными графами
G и H. T-сохраняющий помеченный графовый морфизм f:GH – это такой
помеченный типизированный графовый морфизм, для которого выполняется: 1)
vdom(fv):vtG=vtHfv; 2) edom(fe):etG=etHfe. В параграфе определяется ряд
категорий, самой важной из которой является LTGraphLT(L,A,T), которая
содержит (L,A) -помеченные T-типизированные графы в качестве объектов и
графовые морфизмы, сохраняющие метки и типы.
Для описания ограничений на допустимые виды отношений между
программными сущностями вводятся два множества метаграфов: допустимые и
недопустимые. Эти ограничения отражают семантику языков (моделирования или
программирования), которые используются при разработке программы.
Допустимые графы описывают разрешенные виды отношений между
программными сущностями, недопустимые – запрещенные. Существование
инъективного морфизма из графа, описывающего программные сущности в
каждый из допустимых графов, при одновременном отсутствии инъективных
морфизмов в каждый из недопустимых графов, обосновывает корректность
графовой структуры ПС.
Пусть 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).
В продолжение первой главы формулируется понятие математической
модели программного средства. По определению она представляет собой Tтипизированный (L,A)-помеченный упорядоченный ориентированный граф при
условии существований T-помеченных допустимых и недопустимых графов,
описывающих
семантические
ограничения,
свойственные
языку
программирования (проектной модели) этого программного средства.
Модель программного средства является многоцелевой в силу отсутствия
требования по описанию всех аспектов программы или всех свойств языка
программирования (проектной модели). Множество типов, которые объединяются
во множество T, определяет степень абстракции моделирования. Множества
допустимых и недопустимых графов должны описывать все ограничения,
9
накладываемые на возможные виды отношений между программными
сущностями тех или иных типов. Адекватность модели программного средства,
понимаемая как совпадение свойств модели и программного средства,
достигается благодаря отсутствию принципиальных ограничений на виды
программных сущностей и их свойства, которым можно было бы сопоставить
вершину или ребро модели соответствующего типа. Степень непротиворечивости
модели определяется качеством формирования допустимых и недопустимых
графов, отражающих семантику языка программирования и служащих для
задания ограничений на допустимые виды структур модели.
Продолжение первой главы посвящено раскрытию вопросов адаптации
многоцелевой модели программного средства в соответствии с предметом и
целями моделирования. До использования модели необходимо выполнить
следующую последовательность действий по ее адаптации: 1) идентифицировать
типы вершин и ребер; 2) построить множество допустимых графов; 3) построить
множество недопустимых графов. Первый этап адаптации является ключевым –
на этом этапе в зависимости от целей моделирования устанавливается набор
типов, определяющий концептуальные аспекты, которые сможет описать
синтезируемая модель. Качество реализации последующих двух шагов
определяет степень согласованности модели и ее соответствия семантике языка
реализации программного средства.
В заключение первой главы рассматриваются примеры выполнения шагов по
адаптации для моделирования диаграмм классов UML и программного кода на
языке Java.
Вторая глава посвящена проблеме описания понятия качества программ и
созданного в рамках диссертационного исследования метода формализованного
описания качества программных средств.
В начале главы дано определение понятия качества программных средств.
Обобщая определения существующих стандартов и подходов к работе с
качеством программ, можно заключить, что качество программного обеспечения
– это способность программного продукта к удовлетворению установленных или
предполагаемых потребностей при использовании в заданных условиях. Описаны
основные существующие стандарты и модели качества, которые относятся к трем
типам:
факторы-критерии-метрики,
цели-вопросы-метрики,
«процессы/продукты». Помимо моделей в первой главе приведен обзор
актуальных стандартов качества программных средств – IEEE 1061-98, ГОСТ
28195-89, ГОСТ Р ИСО/МЭК 9126-93, ISO/IEC 9126:2001-4, ISO/IEC 25000.
Далее во второй главе приведен сравнительный анализ существующих
подходов к описанию качества программных средств. Отмечается, что всем
моделям качества характерна иерархическая, древовидная структура, состоящая
из высокоуровневых показателей, которые детализируются показателями более
низких уровней, пока декомпозиция не приводит к атомарным и измеримым
атрибутам. В различных моделях количество уровней иерархии и число
показателей и атрибутов разнятся, и могут быть как ограниченными, так и не
ограниченными. Более ранние модели по своей природе были скорее
качественными, нежели количественными, ввиду недостатка знаний о метриках.
10
Более поздние предлагают более строгий, количественный подход к оценке и
измерению качества. Основной вектор развития моделей качества определяется
попытками сделать все атрибуты качества измеримыми, а также стремлением
разнести на разные уровни качественные и количественные атрибуты.
В продолжение главы приводится сводка основных недостатков
существующих подходов к описанию качества программ.
1. Трудность технологической интерпретации - Отсутствует связь между
показателями качества и их значениями с типовыми проектными решениями,
шаблонами, паттернами и антипаттернами и т.п. Для архитектора,
проектировщика или программиста для оценивания качества информация о
наличии таких типовых проектных решений является более важной, чем значения
тех или иных показателей.
2. Терминологическая несогласованность - параллельно существует и
используется несколько интерпретаций показателей качества и метрик в разных
моделях качества.
3. Неформализованный характер - практически все модели качества
математически не проработаны, поэтому отсутствует возможность доказательств
корректности моделей или формализованного описания каких-либо свойств этих
моделей, способов адаптации и повторного использования
На основе классификации и анализа недостатков существующих моделей
качества формулируются требования к создаваемому в рамках диссертационного
исследования методу формализованного описания качества программных средств,
основными из которых являются: независимость от реализации и типов программ,
возможность анализа свойств составляющих элементов, связь с дизайном и
количественными свойствами программ. В качестве математической основы
формализованного описания качества программ была выбрана теория категорий
как универсальное средство для описания различных концепций, имеющая
мощные средства для абстракции, обобщения и создания универсальных
конструкций.
Для математического представления качества вводится категория качества Q
которая состоит из объектов Ob(Q) и морфизмов Mor(Q). Класс объектов
категории качества представляет концептуальные понятия, характеризующие
качество программных средств и является конечным множеством с разбиением
Ob(Q) 
n
i0
k
i i
Qi , где Qi  {qm
}m1 - множество объектов i-го уровня иерархии, ki -
число элементов множества Qi. На верхнем уровне иерархии находится объект
q10 , отражающий само понятие качества, в максимальной его полноте и
целостности, поэтому k0 =1, на следующих уровнях иерархии количества
объектов удовлетворяет формуле ki+1  2ki, i{1,…n-1}. При этом Qi  Qj =  при i
 j, то есть каждая характеристика качества находится на одном определенном
уровне иерархии. С целью обобщения существующих и будущих стандартов и
моделей качества объектами категории являются все потенциально оцениваемые
атрибуты, связанные с качеством программы. Для обеспечения согласованности
11
каждый такой атрибут отражает ровно одну концепцию качества, и каждой
концепции качества соответствует ровно один атрибут. Определяются процедуры
добавления объектов к категории качества, учитывающие ограничение
взаимнооднозначного соответствия атрибутов и концепций качества.
Класс морфизмов категории качества описывается тремя множествами
Mor(Q) = Morsi(Q)  Mordi(Q)  Morsl(Q) – множеством строгих иерархических
морфизмов Morsi(Q), множеством нестрогих иерархических морфизмов Mordi(Q) и
множеством одноуровневых морфизмов Morsl(Q).
Строгие иерархические морфизмы категории качества.
1)
для любых двух объектов qai , qbi Qi , i{1,…,n} определяется
множество морфизмов Morsi (qai , qbi ) из qai в qbi :

, a  b
i i
Morsi (qa , qb )  
, где 1 i - тождественный морфизм объекта qai .
qa
{1 i }, a  b

 qa
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 b1 Qi 1, такие, что Morsi (qai b1, qbi ) состоит из одного морфизма для каждого
объекта qai b 1. Для всех остальных объектов qai j 1 Qi 1 при ajab
множество
морфизмов является пустым:
i 1,i

{a,b }, a  ab ,
i 1 i
Morsi (qa , qb )  
.

, a  ab
Таким образом, кроме тождественного, не существует других видов строгих
иерархических морфизмов на одном уровне иерархии категории качества.
Остальные строгие морфизмы определяют связи верхнего уровня иерархии с
нижним. Допустима ситуация, когда несколько объектов верхнего уровня связаны
с одним объектом нижнего множеством морфизмов (по одному морфизму на
каждый объект верхнего уровня).
Нестрогие иерархические морфизмы категории качества.
1)
для любых двух объектов qai , qbi Qi , i{1,…,n} определяется
множество морфизмов Mordi (qai , qbi ) из qai в qbi :

, a  b
Mordi (qai , qbi )  
..
{1 i }, a  b

 qa
2)
для любых двух объектов qaj Q j , qbi Qi , при i,j{0,…,n-1}, i<j,
a{1,…,ki}, b{1,…,ki+1},
Mordi (qai 1, qbi )  . .
множество
12
морфизмов
определяется
пустым
3)
для любого объекта qbj Q j , могут существовать объекты вида
qai b Qi , при j>i+1 такие, что Mordi (qai b , qbj ) состоит из одного морфизма для
каждого объекта qai b . Для всех остальных объектов qai l Qi при ajab множество
морфизмов задается пустым:
i, j

{a,b }, a  ab ,
j
i
Mordi (qa , qb )  
.

,
a

a

b

Нестрогие иерархические морфизмы служат для описания связей различных,
не соседних уровней иерархии.
Одноуровневые морфизмы категории качества.
1)
для любых двух объектов qai , qbi Qi , i{1,…,n} определяется
множество морфизмов Morsl (qai , qbi ) из qai в qbi :
Morsl (qai , qbi ) 
2)
{ i, j }, a  b
 a ,b
.

{1
},
a

b
i
 qa
для любых двух объектов qai Qi , qbj Q j , i,j{1,…,n} множество
одноуровневых морфизмов является пустым Morsl (qai , qbj )  .
Одноуровневые морфизмы служат для моделирования взаимосвязей объектов
категории качества, находящихся на одном уровне иерархии.
Категория качества содержит морфизмы, отражающие все возможные связи
атрибутов качества. Для иерархических морфизмов принципиальное значение
имеет направленность – от объектов, находящихся на верхних уровнях иерархии,
к объектам, расположенным на нижних. Иерархические морфизмы от верхних к
нижним объектам образуют конусы. Эта направленность определяет назначение
главное модели качества – последовательное, детализируемое на каждом
следующем уровне иерархии, концептуальное описание понятия качества
программных средств.
Во второй главе сформулированы и доказаны следующие леммы.
Лемма 1. Категория качества является малой категорией.
Лемма 2. Конусы категории качества, образуемые иерархическими морфизмами,
являются произведениями.
В продолжение главы вводится понятие независимости объектов категории
качества. Объекты категории качества qai , i 1,..., n  1 и qcl , l 1,..., n  1 являются
независимыми, если соблюдаются следующие условия:
1)
отсутствуют одноуровневые морфизмы между этими объектами:
Morsl (qai , qcl )   при i=l;
2)
отсутствуют строгие иерархические морфизмы между этими
объектами:
13
Morsi (qai , qcl )   при il;
3)
отсутствуют нестрогие иерархические морфизмы между этими
объектами:
Mordi (qai , qcl )   при il;
4)
подмножества морфизмов, входящих в продолжения конусов,
имеющих в качестве вершин объекты qai и q bj , не пересекаются:
qi
j 1,..., n;k I a
(
 qkj )  (
ql
h 1,..., n; g I c
 qgh )   .
Затем во второй главе формулируется понятие обобщенной модели качества
программных средств. Модель качества представляет собой подкатегорию
категории качества и состоит из конечного числа объектов категории качества и
конечного числа морфизмов между ними. Модель может представлять некоторый
международный или государственный стандарт (например, ГОСТ Р ИСО/МЭК
9126-93, ISO/IEC 25000 и т.п.), стандарт предприятия-разработчика, и т.п. В
подкатегорию категории качества выбираются объекты, представляющие
концепции качества программы, исходя из назначения модели. На рисунке 1
приведена структура модели описания качества в схематическом виде.
q10
1,10,1

q11
q21

2,1n 1,n 1
q1n 1
q1n
...
q1p
...
...
1,1n 1,n
1,0,1p
0,1
1,2
n 1, n
1,2
q2n
q2n 1
n 1, n
 2,3
q3n
n 1, n
 2,4
q4n
n 1, n
 2,5
q5n
...
1, n
2,t 1
...
qrn 1
 rn,t1,1n
qtn1
 rn,t1,n
qtn
Рисунок 1 – Схема модели описания качества.
После примера формализованного описания качества в соответствии со
стандартом ISO/IEC 25000, во второй главе приводятся обоснования соответствия
разработанной модели требованиям, которые явились результатом анализа и
критики принятых подходов к представлению информации о качестве
программных средств.
В заключение второй главы приводятся сведения о методе формализованного
описания качества программных средств. Метод формализованного описания
качества программных средств включает построение категории качества, то есть
формирование множеств объектов и морфизмов категории качества, и
14
формирование подкатегории этой категории качества, то есть выбор объектов и
морфизмов категории качества исходя из целей моделирования. Оба этих шага
предполагают экспертную работу, результаты которой могут быть на разных
уровнях стандартизованы, объединены в репозитории,
базы знаний,
опубликованы в виде хорошо зарекомендовавших себя практик.
По определению категория качества объединяет в своем составе все
возможные показатели качества программ и семантические связи между ними,
они образуют соответственно объекты и морфизмы этой категории. Состав
объектов категории качества основывается на словаре понятий, достаточном для
описания всех свойств предметной области непротиворечивым образом. Объем
словаря понятий потенциально не ограничен. Следует иметь в виду сложность и
неоднозначность, свойственные процессу формирования этого словаря. Наличие
этих свойств обосновывается двумя важными требованиями к составу объектов
категории качества. Во-первых, необходимо иметь такой состав понятий, который
бы покрывал все существующие и будущие запросы для описания концепций,
связанных с моделированием качества. Во-вторых, состав понятий должен быть
непротиворечивым, то есть одним и тем же концептуальным элементам модели
качества не должно соответствовать более одного понятия из словаря. Первое
требование реализуется благодаря открытости состава словаря и множества
объектов категории качества. Ответственность за реализацию второго требования
лежит на эксперте, формирующем понятийный словарь для категории качества.
При формировании словаря эксперту необходимо осуществлять проверки
свойства
согласованности
состава
показателей
качества,
используя
доказательство независимости элементов в модели.
Множество морфизмов категории качества объединяет все отношения,
существующие между объектами категории. Соответственно видам возможных
связей, это множество содержит три подмножества, которые отражают
зависимости между показателями качества, существующих на соседних уровнях,
на одном уровне и на разных, не смежных, уровнях иерархии в модели качества
программы. Выявление и описание этих отношений, так же, как и формирование
множества объектов категории качества представляет собой экспертную работу.
Результаты экспертной работы необходимо подвергать согласованиям и
формализованным проверкам.
Выбор объектов и морфизмов для включения в состав подкатегории качества
зависит от целей моделирования. Выбранные объекты приобретают контекстную
зависимость и интерпретируются в соответствии с предметной областью,
основными элементами которой являются парадигма программирования
(объектно-ориентированная, функциональная, структурная и т.п.), язык
программирования (java, c, lisp и т.п.), тип проекта (веб-приложение, клиентсерверное приложение с «толстым» клиентом, приложение для карманного
компьютера и т.п.). Поэтому при формировании подкатегории качества
необходим контекстный анализ предметной области моделирования.
Процессы формирования множества объектов и морфизмов для категории
качества, выбор объектов и морфизмов для синтеза модели качества программы –
работа экспертов. Эксперты помимо профессиональной интуиции, при
15
выполнении этих видов работ должны использовать математический аппарат,
благодаря которому можно добиться определенных свойств синтезируемой
модели качества:
 строгость слоев модели – на каждом уровне иерархии модели располагаются
объекты определенной степени абстракции, отсутствуют связи, пересекающие
уровни, то есть, определены отношения между показателями качества для
смежных уровней или внутри каждого уровня: Mordl=;
 базисные слои модели – объекты, относящиеся к одному уровню иерархии, не
зависят друг от друга, формируют «базис» показателей качества на этом
уровне иерархии: Morsl=;
 древовидная структура – в модели качества существуют связи только между
показателями качества, принадлежащие к смежным уровням иерархии:
Morsl=  Mordl=;
 согласованность зависимостей – строгий контроль существующих отношений
между элементами модели, проверка отсутствия нежелательных зависимостей.
Третья глава посвящена описанию процесса оценивания качества
программных средств. В начале главы приводятся основы квалиметрии
программных средств, основные понятия теории измерений, за основу которых
взяты адаптированные определения наиболее современного стандарта по качеству
и измерениям программ – ISO/IEC 25000. Рассматриваются виды измерительных
шкал и процесс комплексирования. Представлен обзор наиболее актуальных
стандартов этой области - ISO/IEC 14598-1-6:1998-2001, ISO/IEC 15939, ISO/IEC
25020, ISO/IEC 25021, ISO/IEC 25022, ISO/IEC 25023, ISO/IEC 25024.
Модели измерений, служащей для оценки качества предъявляются
следующие требования: независимость от реализации, возможность анализа
функциональных зависимостей метрик, связи с описанием качества, дизайном и
оптимизацией программ. В качестве математической основы модели была
выбрана теория категорий как универсальное средство для описания различных
концепций, а также функциональный анализ, для с целью использования таких
понятий, как расстояние, метрика, метрическое пространство, линейный
оператор.
В третьей главе рассматриваются метрики, формальное определение которых
базируется на многоцелевой математической модели программных средств.
Базовая метрика представляет собой метрику, определенную в терминах атрибута
и метода его обсчета, является функционально независимой от других метрик.
Производная метрика является метрикой, которая определяется посредством
функции от двух или более значений базовых или других производных метрик,
преобразование метрики с использованием математических функций также
является производной метрикой. Определения базовых метрик основано на
многоцелевой модели программного средства, введенной в первой главе. Базовые
метрики обсчитывают количество вершин, ребер определенного типа и длину
пути графа из ребер определенного типа, используя свойство конечности
множеств вершин V и ребер E модели программы. На основе этих метрик путем
16
комплексирования создаются производные метрики. В третьей главе показан
процесс комплексирования и определены основные типы производных метрик.
В продолжение третьей главы вводится понятие функциональной
эквивалентности программ. Это понятие достаточно широко представлено в
литературе и в описываемом подходе не осуществляется развитие теории
эквивалентности программ, происходит лишь использование понятия
функциональной эквивалентности в самом общем виде – эквивалентности
выходных данных, формируемых программным средством в ответ на тестовый
набор, достаточный для проверки реализации всех функциональных требований.
Такой тип эквивалентности назван в работе слабой функциональной
эквивалентностью. Вводится множество Prog, содержащее все математические
модели конкретного программного средства. Каждое из программных средств
этого множества, будет состоять в отношении слабой функциональной
эквивалентности с другими программными средствами, чьи модели принадлежат
Prog. Между собой эти модели будут отличаться внутренней структурой.
Для описания формализованной модели измерений приводится традиционное
математическое определение этого понятия «метрика»: отображение m:
ProgProg  R называют метрикой на Prog, если m(x,y)=0x=y, m(x,y)= m(y,x),
m(x,y)m(x,z)+m(z,y), при x, y, zProg.
Далее приводится определение метрического пространства: пара (Prog, m)
будет называться метрическим пространством программных средств,
вещественное число m(x, y) – расстоянием между программным средством x и
программным средством y. В однозначном контексте допустимо само множество
Prog называть метрическим пространством.
На базовых (Mb) и производных (Md) метрических пространствах вводится
множество операторов для формального описания процесса комплексирования
производных метрик из других производных и базовых, эти операторы носят
название операторов комплексирования. Операторы комплексирования
Ac:MbMd, Ac:MdMd отражают зависимости одних производных метрик от
других производных или базовых. В зависимости от способов комплексирования,
операторы Ac могут иметь различную природу, быть линейными, нелинейными,
ограниченными, непрерывными и т.п. Далее в параграфе приводятся основные
свойства операторов, определяемых на метрических пространствах.
Продолжение третьей главы посвящено описанию категории измерений.
Категория MS, объектами которой являются метрические пространства Mb и Md, а
морфизмами – операторы комплексирования Ac называется категорией измерений.
Далее в этом параграфе описываются свойства морфизмов этой категории. Затем
описываются понятия произведений и прямых сумм в категории метрик.
В продолжение третьей главы формулируется понятие модели метрик
программных средств. Модель измерений качества программных средств
представляет собой подкатегорию категории измерений MS, в которую в
соответствии с целями моделирования включаются определенные метрические
пространства Mb, Md и операторы комплексирования Ac, входящие в классы
объектов и морфизмов категории MS. На рисунке 2 представлена структурная
схема модели измерений.
17
M d 10
Ac1,0
1,1
M d 12
M d 11
Acn1,1,n 1
M d 1n
...
M d 1p
...
...
M
Ac1,0
p ,1
Ac1,0
2,1
Acn1,21,n 1
d n 1
1
Acn2,1,n 1
M d n2
M
Acnt,11,2
d n 1
2
Acn3,2,n 1
M d 3n
...
cn ,n 1
4,2
A
M d n4
...
M d nr 1
Acn5,2,n 1
Acnt ,n1,r1
Acnt ,,rn 1
M d 5n
M d tn1
M d tn
Рисунок 2 – Схема модели измерений.
В модели измерений, в отличие от модели качества, морфизмы имеют
противоположное направление, образуя коконусы. Таким образом, выявляется
назначение этой модели – фиксировать метрические пространства для оценки
концептуальных понятий качества и определять функциональные зависимости для
порождения значений производных метрик, соответствующих верхним уровням
иерархии за счет комплексирования метрик, соответствующих нижним.
Дальнейшие разделы третьей главы посвящены описанию метода синтеза
модели измерений качества программных средств. Категория измерений
изоморфна категории качества программных средств, служит для
количественного оценивания концептуальных понятий о качестве, определяемых
моделью качества. Метод синтеза модели измерений служит для генерации
модели измерений на основе модели качества с целью реализации этого
оценивания. Для синтеза категории измерений на основе категории качества ПС
определяется функтор. Целью введения функтора является обеспечение
формальной связи между моделями качества и метрик. Функтор QM:QMS
является контравариантным одноместным функтором, отображающим объекты
категории
качества
(характеристики,
подхарактеристики,
принципы
проектирования) на метрические пространства категории метрик (базовые и
производные) QM(Ob(Q))=Ob(MS), а морфизмы категории качества – на
морфизмы категории измерений, являющимися операторами над метрическими
пространствами QM(Mor(Q))=Mor(MS).
Функтор QM:QMS на объектах категории Q задается следующим образом:
1) на объектах:
QM ( i{0,n 1}{qi })  i{0,n 1}{M di } - отображение элементов категории
качества, отвечающих за представление производных метрик, подхарактеристик и
характеристик на производных метрических пространствах.
18
2) на морфизмах
- на морфизмах, принадлежащих парам соседних уровней:
QM (si ,m1,i )  Acim,i,s1 , i{1,…,n}, где Acim,i,s1 - оператор, определенный на
X  M d im , имеющий в качестве области значений Y  M d is1 , соответствующих
i
элементам qm
и qsi 1 ;
- на морфизмах, принадлежащих уровням i, j при j>i+1:
QM (si,,mj )  Ac mj ,,is , i{0,…,n-2}, j{2,…,n}, где Ac mj ,,is
оператор,
-
определенный на X  M d mj , имеющий в качестве области значений Y  M d is ,
соответствующих элементам qmj и qsi ;
- на морфизмах, принадлежащих одному уровню:
i
QM (si,,m
)  Acim,i, s , i{1,…,n}, где Acim,i, s - оператор, определенный на
X  M d im , имеющий в качестве области значений Y  M d is , соответствующих
i
элементам qm
и qsi .
На рисунке 3 схематично показано действе функтора QM .
q10
1,10,1

q1n
q1p
...

q1n1

Ac1,01,1
...
q21
...
n1,n
1,1
1,p0,1
0,1
1,2
q11
M d10
1,2n1,n
q2n

n 1,n 1
2,1
q2n1
2,3n1,n
q3n

n1,n
2,4
q4n
QM (
...
1,n
2,t 1
...
rn,t1,1n
q5n
qtn1
{qi }) 
i{0,n 1}
{M di } M d11
QM (si,m1,i )  Acim,i,s1
QM (si,,mj )  Ac mj,,is
qrn1
2,5n1,n
i{0,n 1}
rn,t1,n
QM (si,,mi )  Acim,i,s
qtn
M d12
...
M d1p
...
...
M
Ac1,0p,1
Ac1,02,1
Acn1,21,n1
d n 1
1
Acn1,1,n1
Acn2,1,n1
M d 1n
M d n2
...
Acnt,11,2
M d n21
Acn3,2,n1
M d 3n
cn ,n 1
4,2
A
M d n4
Acn5,2,n1
M d 5n
...
M d nr1
Acnt ,n1,r1 Acnt ,,rn1
dn
M d tn1 M t
Рисунок 3 – Функтор оценки качества.
С помощью функтора QM, на основе модели измерений MS можно
количественно оценить элементы модели качества Q, сделать это как для
конкретной характеристики, подхарактеристики, принципа проектирования, так и
для качества программного средства в целом.
Метод синтеза модели измерений качества программных средств объединяет
следующие действия:

применение функтора синтеза модели измерений к заранее разработанной
модели качества;
19
подбор базовых и производных метрик для измерения листовых элементов
синтезированной модели измерений;

построение модели программного средства;

математическое описание метрик на основе модели программного средства;

уточнение вида операторов комплексирования;
При описании алгоритма оценивания качества программных средств,
который представлен в следующем параграфе, приведен пример реализации
метода синтеза модели измерений.
Вторая часть третьей главы посвящена описанию алгоритма оценивания
качества программных средств. В начале главы приведены краткие описания
существующих в этой области стандартов, таких как ISO/IEC 14598, ISO/IEC
15939, ISO/IEC 25000. Описаны модели оценки качества, регламентируемые
этими стандартами. В этой части третьей главы представляется алгоритм
оценивания, который является обобщением описанных подходов к оценке
качества (рисунок 4).

[нет]
Цели оценивания достигнуты?
Определение целей оценивания
Разработка модели качества
Генерация модели измерений
Поиск базовых метрик
Анализ качества ПС
Определение фактических значений метрик
Определение пороговых значений метрик
Определение производных метрик
Формализация метрик
Моделирование ПС
Рисунок 4 – Обобщенная модель оценивания качества программ.
В заключение третьей главы каждый из этапов алгоритма оценивания
качества рассматривается подробно, приводятся примеры реализации этих этапов.
С помощью предлагаемого алгоритма существует возможность оценить качество
программного средства в целом, а также любого отдельного компонента модели
качества. Если качество программы не было признано удовлетворительным, на
основе метрик выявляются отдельные дефектные программные сущности,
которые являются кандидатами для проведения рефакторинга, инспекций и
других мероприятий по улучшению качества кода. После проведения этих
мероприятий происходит повторная оценка качества с целью проверки принятых
20
решений по преобразованию программы. При интерпретации результатов оценки
качества может быть принято решение о необходимости внесения изменений в
процесс оценивания. Предприятия по изменению процесса оценки могут быть
следующих типов: изменение модели качества, корректировка состава и
пороговых значений производных и базовых метрик, изменение функциональных
зависимостей, порождающих производные метрики качества.
Четвертая глава посвящена описанию метода оценки степени соответствия
программного средства типовым программным решениям. В диссертационной
работе понятие «типовое программное решение» используется для обозначения
шаблонов проектирования, паттернов, известных практик программирования,
ключевых принципов, использующихся при разработке программ. Типовые
программные решения определяют походы к конструированию программ и
основываются на опыте, накопленном при разработке успешных программных
проектов. Задачей метода оценки степени соответствия программного средства
типовым программным решениям является получение ответа на вопрос,
нарушены ли при проектировании типовые решения, и если да, то какие именно
это решения и какие именно программные структуры их нарушают. Благодаря
такой оценке появляется возможность судить о качестве программного средства в
терминах проектирования, то есть более конструктивно, а также упрощать
процесс оптимизации качества. На рисунке 5 в виде диаграммы бизнес-процессов
UML представлены основные этапы реализации метода оценки степени
соответствия программного средства типовым программным решениям.
[нет]
Определение целей оценивания
Выбор типовых программных решений
Цели оценивания достигнуты?
Анализ нарушений типовых программых решений
Задание допуска нарушений типовых программных решений
Идентификация нарушений с помощью допустимых графов
Описание типовых программных решений с помощью допустимых графов
Описание типовых программных решений с помощью ролей
Идентификация нарушений с помощью ролей
Идентификация нарушений с помощью метрик
Описание типовых программных решений с помощью метрик
Построение модели ПС
Рисунок 5 – Этапы метода оценки степени соответствия программного
средства типовым программным решениям.
21
В последующих разделах четвертой главы этапы метода оценки
рассматриваются подробно. В заключение главы приводится сравнительный
анализ трех основных способов описания и идентификации типовых
программных решений: с помощью допустимых графов, с помощью ролей и с
помощью метрик. Описание типовых программных решений с помощью
допустимых графов используется, если нужно максимально детально задать
структуру типового решения. Это наиболее трудный в использовании и мощный
по выразительности способ описания типовых программных решений. Способ
описания типовых программных решений с помощью ролей используется, если
необходимо контролировать правильность реализации типовых программных
решений, которая выражается в определенных запретах на виды отношений
между программными сущностями. Этот способ значительно проще использовать
по сравнению с допустимыми графами. Способ описания типовых программных
решений с помощью метрик целесообразно использовать при условии, что
критерии реализации типовых программных решений носят количественный
характер. Этот способ несколько проще, чем способ описания типовых
программных решений с помощью допустимых графов. С помощью этого способа
можно получить количественную оценку степени соответствия фрагмента кода
программному решению, в отличие от двух альтернативных способов, где оценка
носит бинарный характер.
Пятая глава посвящена описанию принципов оптимизации программных
средств, используемых, если результаты процесса оценивания не удовлетворяют
принятым критериями качества. При разработки модели учитывались следующие
такие требования как независимость от реализации, связь с моделью программ –
объектом оптимизации, связь с моделью измерений программ – критерием
оптимизации. В качестве математического базиса используется теория перезаписи
(или переписывания) графов, так как она базируется на теории графов, которая
лежит в основе модели программы, а также позволяет просто и наглядно
описывать преобразования графов. Идея перезаписи графа состоит в описании в
левой части продукции тех вершин и ребер, которые должны иметься в исходном
графе, а в правой – как эта часть графа будет выглядеть после применения
продукции. Частичный морфизм описывает отношения объектов левой части к
правой, детализируя процесс применения правила. Объекты, не описываемые
морфизмом, удаляются, объекты, не изменяемые морфизмом, формируют
контекст продукции, объекты правой части продукции, не имеющие прообраза в
r
 R) состоит из имени
левой части создаются заново. Продукция p : ( L 
продукции p и инъективного частичного графового морфизма r, называемого
морфизмом продукции. Графы L и R носят названия соответственно левой и
правой частей продукции.
Система перезаписи графов Θ=({G0},P), содержит {G0} - множество
начальных графов и P - множество продукций. Далее в этом параграфе следуют
определения элементов теории перезаписи, положенные в основу модели
преобразования программных средств: графовая грамматика, соответствие,
вывод, графовый язык и другие. Используется понятие составных продукций,
22
которые представляют собой упорядоченные последовательности продукций.
Элементарные продукции объединяются в составные, рассматриваемые как
атомарное действие, по аналогии с программной концепцией транзакции. В итоге,
или вся упорядоченная последовательность элементарных продукций
выполняется, или невозможность выполнения одной из продукций влечет отмену
выполнения всех остальных продукций, входящих в последовательность. Для
двух продукций p1:L1R1 и p2:L2R2 при R1=L2 продукция последовательной
p
композиции p1; p2 : L1 
 R2 состоит из
соответствующего
частичного
морфизма
p
m1
имени продукции p1;p2 и
p=p2p1.
Выводы
вида
p
m2
1
2
G 
 H1 
H 2 , в которых соответствие второго прямого вывода m2
является косоответсвием первого, могут быть реализованы за один шаг с
помощью составной продукции p1; p2 . Обратно, каждый прямой вывод вида
p ;p
m1
1 2
G 
 H2
может быть с помощью
p1; p2
декомпозирован в вывод
1
2
G 
 H1 
H 2 , при условии, что косоответствие m1 первого вывода

p
m1
p
m1
является тотальным.
Далее в пятой главе рассмотрены различные варианты последовательного
применения продукций, с возможной синхронизацией общедоступных для
продукций элементов графа. Благодаря введению условий преобразования
появляется возможность описать, в каких именно случаях исходные графы можно
преобразовать к целевым. Условная перезапись графа является такой перезаписью
графа, в которой каждая продукция p:LR содержит множество условий.
Последние разделяются на подмножества предусловий и постусловий.
Предусловия описывают ограничения, несоблюдения которых ведет к
невозможности выполнения продукции, постусловия – ограничения, которым
должен удовлетворять результирующий граф после выполнения продукции.
Подмножества пред- и постусловий состоят из подмножеств позитивных и
негативных условий. Позитивные условия описывают «положительные»
ограничения для L или R и обычно состоят в требовании существования
некоторых вершине или ребер для того, чтобы можно было выполнить
продукцию. Обратно, негативные условия вносят требования об отсутствии
некоторых вершин или ребер в L или R.
Продукция с условием применения, или условная продукция
p
p : ( L 
 R, ac( p)) состоит из имени продукции p’ и двойки – частичного
графового морфизма p и условия применения ac(p) над графом L. Продукция
m
 G, если m удовлетворяет ac(p). В
является применимой к графу G при L 
p
m
 H носит название прямого условного вывода
этом случае, прямой вывод G 
p
m
G  H . Условие
ac(p)
в
условной
23
продукции
разделяется
на
два
подмножества - ac(p)L - предусловий (условий применения над исходным графом)
и ac(p)R - постусловий (условий применения над результирующим графом).
В продолжение пятой главы на основе описанных ранее структур перезаписи
графов представлен подход к описанию преобразований программных средств.
Для формального описания преобразований программ используются только
инъективные тотальные соответствия m:LG, инъективные продукции p:LR и
преобразования, сохраняющие метки и типы, то есть морфизмы введенной в
первой главе категории LTGraphLT. Все возможные пути преобразований
описываются с помощью конечного множества элементарных продукций. Набор
элементарных преобразований определяется структурой графа, моделирующего
программное средство. Над этим графом можно осуществлять следующие виды
преобразований: добавлять или удалять вершины и ребра, изменять метки или
типы вершин и ребер. Эти преобразования формируют множество из восьми
элементарных преобразований: 1) добавление вершины - InsertV; 2) добавление
ребра - InsertE; 3) удаление вершины - DropV; 4) удаление ребра - DropE; 5)
изменение типа вершины - RetypeV; 6) изменение типа ребра - RetypeE; 7)
изменение метки вершины - RelabelV; 8) изменение метки ребра - RelabelE. Первые
четыре преобразования формируют базис преобразований, так как остальные
четыре могут быть выражены с помощью них. Более того, только преобразования
с 1 по 4 относятся к категории LTGraphLT, то есть в рамках только этих
преобразований сохраняются и типы и метки. Преобразования 5 и 6 относятся к
категории LTGraphL, а последние два – к категории LTGraphT. Таким образом,
первые четыре преобразования не нарушают типы и метки графа и являются
достаточными для описания любого типа преобразования. Остальные типы
введены для упрощения описания процесса преобразования.
Из
элементарных
преобразований
может
быть
образована
последовательность, за несколько шагов приводящая граф из начального в
конечное состояние. Последовательность из n элементарных преобразований
требует для своего выполнения формирования n-1 промежуточных графов.
Альтернативным вариантом является объединение нескольких элементарных
преобразований в составные, которые консолидируют все преобразования графа в
одной продукции и рассматриваются в этом смысле как атомарные. Составное
преобразование pC представляет собой композицию условных продукций
pC=p1p2…pn: G0Gn.
В продолжение пятой главы на метрических пространствах Mb вводятся
операторы преобразований. Назначение операторов состоит в изменении
значений базовых метрик, путем преобразования модели программного средства.
Множеству таких операторов принадлежат операторы добавления и удаления
вершины (ребра) для всех типов вершин и ребер.
Базовые операторы преобразований Atb:MbMb соответствуют элементарным
преобразованиям графовых моделей программных средств, определяемым
базисом
Pb={InsertV,InsertE,DropV,DropE}.
Производные
операторы
td
d
d
преобразований A :M M соответствуют составным преобразованиям графовых
24
моделей ПС, определяемых композициями условных продукций вида
pC=p1p2…pn:G0Gn.
На основе техники перезаписи графов и приведенных определений
элементарных, составных преобразований в пятой главе формулируется
определение модели оптимизации качества программных средств. Эта модель
основана на многоцелевой модели программных средств и модели измерений,
включает базовые и производные операторы преобразований, удовлетворяющие
следующим условиям:
 могут быть выражены базисом, который включает морфизмы удаления и
добавления ребра и вершины каждого типа;
 существуют инъективные морфизмы из графов левых и правых частей
продукций преобразований в каждый из допустимых графов модели ПС;
 не существуют инъективные морфизмы из графов левых и правых частей
продукций преобразований в каждый из недопустимых графов модели ПС.
Модели оптимизации программных средств свойственен обобщенный
характер, перед ее использованием для формализации описания преобразований
конкретного программного средства, эта модель должна пройти стадию
адаптации, которая включает следующую последовательности действий:
 определение базиса преобразований, состоящего из множества элементарных
преобразований удаления и добавления вершины и ребра каждого из
допустимых типов, вместе с их пред- и постусловиями;
 синтез составных преобразований – представляет собой экспертную работу,
цель которой состоит в упрощении процесса описания преобразований за счет
объединения элементарных преобразований в наиболее употребительные
составные;
 анализ составных преобразований – проверка согласованности левых и правых
частей составных преобразований с допустимыми и несогласованности с
недопустимыми графами.
Далее в пятой главе рассматриваются примеры реализации этих действий
применительно к программным средствам, выраженных с помощью диаграмм
классов UML и объектно-ориентированного кода на Java.
Следующие разделы главы посвящены описанию алгоритма оптимизации
качества программных средств. Основной задачей этого алгоритма является
выбор последовательности преобразований на основе анализа соотношений
эталонного (дефектного) подпространств и расположения точки в метрическом
пространстве, характеризующей оценку качества программы (или ее сущностей).
В качестве основы алгоритма оптимизации выступают алгоритмы поиска
оптимальной композиции операторов Atb:MbMb и Atd:MdMd модели метрик и
алгоритма нормализации составных преобразований. На основе первого
алгоритма сформирована последовательность преобразований, на основе второго
эта последовательность нормализована. На рисунке 6, с использованием
диаграммы действий UML, представлена схема алгоритма оптимизации качества
программных средств.
25
Применение последовательности преобразований
Оценка качества
[да]
Качество ПС удовлетворительное
[нет]
Поиск сущностей дефектных подпространств
Нормализация последовательности преобразований
Поиск оптимальной последовательности операторов преобразований
Рисунок 6 – Этапы алгоритма оптимизации качества программных средств.
Поиск сущностей дефектных подпространств осуществляется на основе
заданных пороговых значений метрик. Те сущности программы (например,
классы, методы и т.п.), для которых значение определенной метрики не
принадлежит пороговому интервалу, классифицируются как дефектные и
являются кандидатами на применение преобразований. На каждом метрическом
пространстве, соответствующем базовой метрике задан базовый оператор
преобразований Atb:MbMb, соответствующий элементарным преобразованиям
графовых
моделей
ПС,
которые
определяются
базисом
Pb={InsertV,InsertE,DropV,DropE}. На каждом метрическом пространстве,
соответствующем производной метрике, может быть определено m (m1)
производных операторов преобразований Atd:MdMd, которые соответствуют
составным преобразованиям графовых моделей программ, определяемых
композициями условных продукций вида pC=p1p2…pn:G0Gn. Таким образом, в
случае необходимости изменить модель программы относительно базовой
метрики выбор оператора оказывается однозначным, при необходимости
изменения модели программы относительно производной метрики определяется
способ многокритериального выбора нужного производного оператора из mсуществующих. Каждый из производных операторов может характеризоваться
побочным эффектом, состоящем в том, что помимо изменения значения целевой
метрики, оператор может изменить значения других метрик, ухудшив при этом
качество
программного
средства.
Алгоритм
поиска
оптимальной
последовательности преобразований позволяет учесть влияние побочных
эффектов на качество программы, и до выполнения преобразований выбрать
наиболее оптимальную в смысле улучшения качества последовательность
преобразований. Идея алгоритма состоит в генерации всех возможных
последовательностей преобразований, согласованных в смысле соблюдения пост26
и предусловий (рисунок 7), оценка результата их применений и выбор
последовательности, применение которой влечет наибольшее изменение качества
программы. Под оптимальным изменением качества понимается максимальная
близость точки в многомерном метрическом пространстве, характеризующей
текущее состояние программного средства к точке, соответствующей эталонному
состоянию. Проблема точной достижимости эталонной точки является трудно
разрешимой. В «идеальном» смысле за счет применения базовых и производных
операторов, можно достичь любой точки многомерного метрического
пространства. Проблема «реальной» достижимости возникает благодаря
ограничениям на области действия базовых и производных операторов
метрических пространств, которые являются следствием необходимости учета
следующих факторов:
 семантики языка – например, нельзя создать класс одновременно не
имеющий функции-члены и данные-члены и наследования (С++), нельзя
создать класс без наследования (Java) и т.п.;
 семантики программы – операторы преобразований в метрических
пространствах должны быть безопасны по отношению к функциональным
свойствам программы.
Исходя из трудности формализации семантик языка и реальной программы, в
основу алгоритма генерации последовательности преобразований положен
прямой перебор всех возможных вариантов преобразований, с последующим
оцениванием каждого варианта и выбором наилучшего из них.
Дефектное подпространство n-мерного пространства модели измерений
Составляющие дефектного подпространства:
M d1
...
M d2
ac( A1td 1 ) L
td 1
A1td 1 ac( A1 ) R
ac( A1td 2 ) L A1td 2 ac( A1td 2 ) R
ac( A2td 1 ) L
td 1
A2td 1 ac( A2 ) R
ac( A2td 2 ) L A2td 2 ac( A2td 2 ) R
ac( A3td 1 ) L
td 1
A3td 1 ac( A3 ) R
ac( A3td 2 ) L A3td 2 ac( A3td 2 ) R
ac( A4td 1 ) L
td 1
A4td 1 ac( A4 ) R
ac( A4td 2 ) L A4td 2 ac( A4td 2 ) R
ac( A5td 2 ) L A5td 2 ac( A5td 2 ) R
...
M dn
ac( A1tdn ) L
tdn
A1tdn ac( A1 ) R
ac( A2tdn ) L
tdn
A2tdn ac( A2 ) R
...
...
ac( A6td 2 ) L A6td 2 ac( A6td 2 ) R
Последовательности операторов преобразований
Рисунок 7 – Схема образования последовательностей операторов преобразований.
27
Алгоритм поиска оптимальной последовательности преобразований
Данные алгоритма
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( A j ) R  ac( Ahtdi 1) L выполнить
Шаг 2.2.1. Al  A j Ahtdi 1
Шаг 2.2.2. U=UAi
Шаг 2.2.3. l=l+1
Шаг 3. i=i+1
Шаг 4. Если i<n то выполнить produceAChain(U,i)
Основной алгоритм
Шаг 1. Положить i  1, R 
m
l 1
Altdi , где m - количество операторов на i-
том метрическом пространстве
Шаг 2. Выполнить produceAChain(R,i)
Шаг 3. Оценить значения производной метрики, соответствующей
понятию качества программы m  M1d 0 для каждого производного
оператора AiR и выбрать тот оператор Ai, для которого значение
метрики качества является наиболее близким к установленному
эталонному интервалу.
Далее в главе вводится алгоритм нормализации, служащий для оптимизации
составных преобразований, соответствующих найденному оптимальному
производному оператору. Каждая из полученных с помощью представленного
алгоритма нормальных форм содержит одно и тоже множество элементарных
преобразований, при этом последние могут быть по-разному упорядочены. В
пятой главе формируется и доказывается следующая лемма.
Лемма 3. Уникальность нормальной формы. Каждая нормальная форма
составного преобразования уникальна с точностью до переупорядочения
элементарных преобразований, входящих в ее состав.
Необходимо заметить, что в минимальном составном преобразовании
порядок следования однотипных преобразований не является произвольным в
28
силу того, что они в общем случае последовательно зависимы. Основные
преимущества нормализованного составного преобразования состоят в
минимальности числа элементарных преобразований и в упорядоченности
однотипных преобразований.
Шестая глава посвящена описанию общих принципов управления качеством
программных средств. В начале главы в качестве итога по предыдущим главам,
приведен анализ разработанных моделей, в частности исследованы наиболее
важные их свойства – адекватность и эффективность. Адекватность моделей – это
идентичность, схожесть модели по определенным показателям с объектом
моделирования, согласие между поведением модели и реального объекта. Не
менее важным критерием оценки модели является эффективность - практическая
полезность модели, например, время и трудоемкость ее анализа. Процесс
моделирования неизбежно протекает в условиях диалектического взаимодействия
двух противостоящих друг другу тенденций – возможно более полного и точного
воспроизведения в модели свойств и характеристик реального объекта и
упрощения методов работы с моделью. Стремление к полноте описания свойств
моделируемого объекта влечет рост сложности – количества типов элементов
модели и связей между ними. Наилучшее в практическом отношении качество
модели достигается как компромисс между адекватностью и эффективностью. В
таблице 1 приведены принципы обеспечения адекватности и эффективности в
разработанных моделях.
Таблица 1 – Адекватность и эффективность разработанных моделей.
Модель
Обеспечение адекватности
Обеспечение эффективности
Многоцелевая
обеспечивается
в состав типов вершин и ребер
математическая соответствием
типов могут включаться только те,
модель
вершин и ребер типам которые
используются
для
программных
программных сущностей и оценки
или
оптимизации
средств
связей
между
ними; качества
корректность проверяется
допустимыми
и
недопустимыми графами
Обобщенная
возможность
отражать вариативный состав показателей
математическая любое понятие о качестве; и
связей
между
ними,
модель качества возможность
проверки вариативное количество уровней
программных
независимости показателей иерархии
средств
Математическая соответствие
модели вариативный
набор
базовых
модель
измерений модели качества; метрик; возможность выбора
измерений
различных
видов
качества
функциональных зависимостей
программных
показателей
средств
Математическая базис видов преобразований с
помощью
составных
29
Модель
Обеспечение адекватности
Обеспечение эффективности
модель
соответствует
преобразований может быть
оптимизации
многоцелевой
сформирован каталог наиболее
качества
математической моделью значимых преобразований
программных
программных средств
средств
Далее в главе рассмотрены принципы использования разработанных моделей.
Обобщая основные подходы к управлению качеством проектов, можно выявить
три основных процесса, лежащие в основе системы управления качеством:

процесс планирования качества – отвечает за определение того, какие из
стандартов качества относятся к данному проекту и как их удовлетворить;

процесс обеспечения качества – обеспечивает выполнение плановых
систематических операций по качеству, выполнение всех предусмотренных
процессов, необходимых для того, чтобы проект соответствовал оговоренным
требованиям;

процесс контроля качества – осуществляет мониторинг контрольных точек
процессов разработки с целью определения их соответствия принятым
стандартам качества и определяет пути устранения причин, вызывающих
проблемы реализации этих процессов.
В настоящий момент основными слабыми сторонами реализации этих
процессов являются:
 ориентация на качественные, а не количественные показатели,
характеризующие состояние разрабатываемого программного средства;
 низкая степень формализации действий внутри процессов, не возможность
формализованных моделирования и верификации процессов и состояний
программного средства;
 отсутствие учета хорошо зарекомендовавших себя практик и типовых
программных решений на системном формализованном уровне;
 низкая степень автоматизации;
 отсутствие формализованных, верифицируемых данных о связывании
качественных состояний программного средства и подходами к его
оптимизации.
Использование на каждом из этих процессов разработанных моделей и
методов по работе с качеством позволит обеспечить необходимый уровень
формализации и системности работ по улучшению качества программных
средств. На рисунке 8 показано распределение разработанных моделей и методов
по процессам планирования, обеспечения и контроля качества программных
средств.
30
Процесс планирования
качества
Управление проектом
Алгоритм управления
качеством программных
средств
Метод
формализованного
описания качества
программных средств
Управление процессами
Модель качества
Процесс обеспечения качества
Многоцелевая
математическая модель
программных средств
Процесс управления
изменениями
Алгоритм
оптимизации
программных средств
Выполненные
преобразования
Математическая модель
измерений качества
программных средств
Метод синтеза модели
измерений
Модель измерений
Процесс контроля качества
Математическая модель
оптимизации программных
средств
Рекомендуемые
преобразования
Метод оценки степени
соответствия программного
средства типовым
программным решениям
Рисунок 8 – Использование разработанных моделей и методов при
реализации проектных процессов.
Следующее изложение главы посвящено описанию структуры системы
управления качеством программных средств. Объектом управления системы
является модель программного средства, модель качества формирует внешнюю
среду. В общем виде компоненты системы управления качеством и их
взаимодействие показаны на рисунке 9. Номера обозначают последовательность
при взаимодействии подсистем.
Программное
средство
Подсистема моделирования ПС
1
Подсистема реализации преобразований
2
Модель
ПС
Код
Исходный
код
Исходный
код
Модель
ПС
6
Преобразован
ная модель ПС
Модель ПС
Преобра
зованная
модель
ПС
Код
Модель
ПС
Подсистема моделирования
качества
Преобразования
Подсистема идентификации
состояний ПС
3
4
Модель
качества
Модель
измерений
Модель
измерений
Классы
качественног
о состояния
ПС
(обучающая
выборка)
Подсистема формирования
преобразований
5
Классифика
ция
качественног
о состояния
ПС
Состояние
ПС
Виды
преобразова
ний
состояний
сущностей
модели ПС
Выбранный
набор
преобразова
ний модели
ПС
Рисунок 9 - Общая структура системы управления качеством программных
средств.
31
Идентификация состояния программного средства представляет собой
принятие решения о принадлежности этого состояния к определенной
классификационной категории. Формирование преобразований представляет
собой принятие решения, состоящее в выборе набора преобразований
программного средства, оптимального по определенному критерию. В
подсистемах идентификации и формирования преобразований классы
используются как для идентификации текущего состояния, так и для
формирования преобразований с учетом состояния программного средства
после реализации этих преобразований.
В следующих разделах шестой главы формулируются требования к
методам классификации и приводится их сравнительный анализ. На основе
достоинств и недостатков существующих в этой области методов, учитывая
специфику задачи классификации состояний программного средства,
состоящую в нечетком разделении классов и плохой формализации задачи,
делается вывод о целесообразности использования средств искусственного
интеллекта в качестве методов классификации системы управления
качеством программных средств.
В продолжение шестой главы обоснована целесообразность и показано
место методов кластерного анализа в системе управления качеством
программных средств. В рамках кластерного анализа целесообразно
использовать репозитории программных средств, качественное состояние
которых заранее известно. Это могут быть как состояния «эталонное
программное средство» или «дефектное программное средство», с
известными соответствующими положительными или отрицательными
свойствами, так и состояния программных средств, отвечающие
определенным моделям качества в той или иной мере. Приведен пример
кластерного анализа программных сущностей. Результирующие состояния
программы, объединенные в кластер, мало различаются по факторам,
детерминирующим перевод программы в эти состояния. Это означает, что
одно и то же преобразование при одних и тех же предпосылках (исходном
состоянии и предыстории объекта управления и среды) могут привести к
переводу программы в одно из результирующих состояний, относящихся к
одному кластеру. Поэтому кластерный анализ результирующих состояний
является инструментом, позволяющим изучать вопросы устойчивости
управления качеством программных средств. При формировании
преобразований как суперпозиции факторов часто возникает вопрос о замене
одних преобразований другими, имеющими сходное влияние на перевод
программы из данного текущего состояния в заданное целевое состояние.
Кластерный анализ преобразований позволяет решить эту задачу – при
невозможности применить некоторое преобразование его можно заменить
другим из того же кластера. В соответствии с предлагаемым подходом
кластеры формируются для заданного диапазона классов с различными
критериями включения качественного состояния программы в кластер. Эти
критерии могут быть сформированы автоматически, на основе репозитория
32
программных средств, качество которых изначально известно, либо заданы
экспертами.
Далее в главе описывается алгоритм функционирования системы
управления качеством программных средств (рисунок 10). Приводятся
описания шагов алгоритма.
Шаг 1. Определение общих требований к качеству программного
средства: построение модели качества, модели измерений. Происходит
детализация понятия качества программы. Выбираются показатели качества,
типовые программные решения, которые являются важными с точки зрения
качества и которые в дальнейшем необходимо будет оценить. Строится
модель качества, включающая показатели как объекты. С помощью
морфизмов модели качества отражаются иерархические и одноуровневые
отношения между показателями и типовыми программными решениями. С
помощью контравариантного функтора из модели качества формируется
модель измерений, в которой каждому показателю или типовому
программному решению модели качества соответствует производная
метрика. Все эти работы реализуются обобщенно, без учета конкретной
специфики проекта. Формируемые требования к модели качества по своей
природе являются противоречивыми, здесь на основе работы экспертов
находится компромисс, учитывающий взаимовлияния показателей качества.
Шаг 2. Определение требований к качеству с учетом языка
разработки: детализация модели измерений (подбор базовых метрик и
определение функциональных зависимостей между метриками). На основе
анализа конструкций языка программирования или моделирования,
экспертами определяются базовые метрики, подходящие для оценивания
производных метрик. В дальнейшем использованные для определения
базовых метрик языковые конструкции ложатся в основу типов вершин и
ребер обобщенной математической модели программного средства. Объекты
модели измерений дополняется этими базовыми метриками. Экспертами
детализируются функциональный вид операторов комплексирования модели
измерений для задания зависимостей между объектами модели измерений.
Шаг 3. Разработка (мета-) модели программного средства –
объединение типов вершин и ребер достаточных для описания метрик.
На основе анализа модели качества выбираются значимые сущности и
отношения программного средства, которые становятся типами вершин и
ребер. Модель программы должна описывать только те из них, которые
отвечают задаче оценки качества в соответствии с определенной моделью
качества. Решение о составе множества языковых конструкций, подлежащих
моделированию, принимается на основе модели измерений при определении
набора базовых метрик.
Шаг 4. Определение типов элементарных преобразований.
Формируется перечень элементарных преобразований, базис которых
представляет собой удаление и добавление вершины или ребра каждого типа.
33
Дополнительно могут определяться такие операции как переименование,
изменение типа и другие преобразования программного средства.
Шаг 5. Определение составных преобразований программного
средства. На данном шаге элементарные преобразования комбинируются в
составные. Каждое составное преобразование соответствует перевод
программной сущности программного средства из одного класса состояния в
другое.
Шаг 6. Формирование классов качественного состояния
программного средства (определение экспертами граничных значений
метрик для разных классов, создание базы данных программных средств и
классификация их экспертами или системой на основе репозитория
программных средств). Информация о модели измерений, программного
средства и элементарных преобразованиях поступает на вход подсистемы
обучения с учителем. Экспертами сообщается системе диапазоны значений
метрик для всех типов программных сущностей. Выбираются шкалы оценки
состояний (например, «эталонное», «дефектное»). На вход системы также
могут быть поданы программные средства, состояние качества которых
заранее известно для формирования репозитория программных средств.
Система фиксирует значения метрик программных сущностей этих
программных средств. Эксперты анализируют и корректируют результаты
анализа программного средства системой. Таким образом формируется
обучающая выборка. Эта обучающая выборка обрабатывается обучающим
алгоритмом, на основе чего формируются решающие правила (классы
состояний программного средства, отражающие весь спектр будущих
возможных состояний), а также определяется ценность метрик для
возможного снижения размерности метрического пространства. Метрики, не
имеющие особой ценности, могут быть удалены из системы.
Шаг 7. Создание модели конкретного программного средства. На
основании определенных типов вершин и ребер строится модель
программного средства, качество которой подлежит оценке.
Шаг 8. Оценивание качественного состояния конкретного
программного средства (распределение сущностей программного средства
по классам состояний). Осуществляется применение решающих правил,
выработанных на шаге 6. В подсистеме идентификации предусмотрен режим
добавления классифицируемой выборки к обучающей, чтобы в
последующем, когда будет известна степень соответствия прогноза
результатам преобразований программного средства, этой верифицированной
оценочной информацией дополнить обучающую выборку и переформировать
решающие правила для реализации обратной связи.
Шаг 9. Выбор составного преобразования, переводящего сущности
программного средства из дефектного в эталонный классы состояний. Из
сформированных на шаге 5 преобразований выбирается составное
преобразование, которое сможет перевести сущности программного средства,
34
находящиеся в классе состояний, который был оценен как дефектный, в класс
эталонного состояния. Составное преобразование ищется на основе
операторов того метрического пространства, метрика которого ниже
эталонной. Это составное преобразование проходит процедуру оптимизации,
состоящую в выборе за счет операторов комплексирования и процедуры
нормализации минимально трудоемкой, потенциально менее опасной
композиции элементарных преобразований.
Шаг 10. Реализация выбранного составного преобразования. На
данном шаге происходит реализация выбранного на шаге 9 составного
преобразования.
Шаг 11. Генерация исходного кода на основе преобразованной
модели. Происходит генерация исходного кода на целевом языке системы.
Шаг 12. Проверка сохранения функциональных свойств.
Осуществляется путем компиляции исходного кода, сгенерированного на
шаге 11, получении исполняемых модулей ПС и запуска пакета
функциональных тестов, состав которого позволяет сделать вывод о том, что
осуществленные преобразования не повлияли на функциональные свойства
программного средства. Альтернативным вариантом является верификация
корректности преобразования.
Шаг 13. Повтор шагов 8-12 до тех пор, пока качественное
состояние программного средства не будет соответствовать эталонному.
Шаг N. Верификация решающих правил. Если решающие правила
построены и оптимизированы, но качество их работы неизвестно, то
пользоваться ими для принятия решений опрометчиво. Верификация
решающих правил основана на использовании внутреннего критерия
качества алгоритма классификации и может быть выполнена в любой момент,
например по требованию экспертов, в обязательном порядке  после каждой
адаптации к изменению модели качества. Для выполнения данной функции
обучающая выборка копируется в классифицируемую, осуществляется ее
автоматическая классификация, ее результаты сравниваются с независимой
экспертной классификацией. На основе этого рассчитываются показатели
качества решающих правил (все эти работы полностью автоматизированы).
35
Определение общих требований к качеству ПС: построение модели качества, модели
измерений
1
Определение требований к качеству с учетом языка разработки: детализация модели
измерений (подбор базовых метрик и определение функциональных зависимостей между 2
метриками)
Разработка (мета-) модели ПС – определение типов вершин и ребер достаточных для
описания метрик
3
Определение типов элементарных преобразований ПС
4
Формирование составных преобразований ПС
5
Формирование классов качественного состояния ПС (определение экспертами граничных
значений метрик для разных классов, создание базы данных ПС и классификация их 6
экспертами)
Создание модели конкретного ПС
7
Оценка качественного состояния конкретного ПС (распределение сущностей ПС по
классам состояний)
Нет
8
Имеются сущности в
дефектных подпространствах
Да
Выбор составного преобразования, переводящего сущности ПС из дефектного в
эталонный классы состояний
9
Реализация выбранного составного преобразования
10
Генерация исходного кода на основе преобразованной модели
11
Проверка сохранения функциональных свойств
12
Рисунок 10 - Алгоритм управления качеством программного средства.
В заключительной, седьмой главе описаны результаты практического
апробирования моделей, методов и алгоритмов управления качеством
программных средств. Приведены результаты шести проектов, в результате
которых были созданы программы для оценивания и управления качеством.
Каждое из программных средств обладает функциональной целостностью и
реализует подмножество описанных в предыдущих главах диссертации моделей и
методов по работе над качеством программ. Одно из средств в качестве входа
использует объектно-ориентированную модель в нотации диаграмм классов UML,
два средства работают с кодом на С++, два – с кодом на Java, один с кодом на C#.
Для апробирования разработанных средств были выбраны два программные
средства, созданные в результате опытно-конструкторских работ (ОКР) Базикмед,
36
Телемед, Кладезь и Автография. ОКР Базикмед разрабатывался в период с 1998
по 2006 годы, цель разработки – создание системы автоматизации
технологических процессов лечебных учреждений Министерства Обороны РФ.
Специальное программное обеспечение было построено с использованием
трехуровневой архитектуры, компоненты бизнес-логики были написаны на Java,
представлены порядка восемьюстами классов. Специальное программное
обеспечение Базикмед содержит отдельный модуль построения отчетов,
написанный на С#. ОКР Телемед был посвящен созданию программной системы
для телемедицинских консультаций, создавался с 2000 по 2006 годы. Специальное
программное обеспечение Телемед содержит около пятисот классов на языке
C++. Специальные программные средства ОКР Кладезь и Автография
реализованы на C# и содержат соответственно 600 и 700 классов. Все работы по
улучшению качества программного обеспечения были произведены в период
доработки опытных образцов по результатам Государственных испытаний.
Работы по качеству касались структуры опытных образцов изделий, и не
затронули функциональных свойств.
В количественном отношении использование программных средств,
основанных на моделях и методах оценивания и управления качеством программ,
помогло сократить около 1 чел/мес. трудозатрат на каждую новую версию
программного продукта, а также обеспечить выявление около 20% новых
программных дефектов.
37
ЗАКЛЮЧЕНИЕ
В описываемой диссертационной работе выполнены анализ и разработка
моделей, методов и алгоритмов, предназначенных для формализации процессов
оценивания и управления качеством программных средств. Важность задач,
решаемых программными средствами в настоящее время, существенные пробелы
в современном состоянии программной инженерии и, в частности, в обеспечении
качества программ, обосновывают высокую актуальность осуществленных
исследований. Использование созданных моделей, методов и алгоритмов сделало
возможным:
 описание понятия качества программных средств с варьируемой степенью
детализации, от концепции – к измерениям с целью нахождения компромисса
между высоким качеством, полнотой реализуемых функций, необходимых
временных, денежных, людских и других ресурсов и создания
консолидированного взгляда на качество программ с точки зрения заказчиков,
разработчиков и пользователей;
 разработку шаблонов описаний качества и моделей измерений программ, для
создания корпоративных, государственных и мировых стандартов в области
качества программ;
 разработку
каталога
качественных
архитектурных
решений,
автоматизированный поиск компонентов программы, которые нарушают
правила использования шаблонов программирования, автоматизированную
подготовку действий по исправлению ошибок в использовании шаблонов
проектирования;
 формализацию
процесса
оценивания
качества
для
создания
внутрикорпоративных, аудиторских и прочих стандартов определения качества
программ;
 онлайновый мониторинг показателей качества для точного управления
процессом разработки программных средств;
 создание интеллектуальных систем, моделирующих действия эксперта путем
классификации качественных состояний программ в зависимости от значений
метрик;
 математическое описание процесса рефакторинга и иных видов
преобразований для автоматизации процесса оптимизации качества
программных средств;
 разработку интеллектуальных систем, моделирующих действия эксперта по
выбору видов преобразований программы для оптимизации ее качественного
состояния;
 создание систем, автоматизирующих полный цикл процессов управления
качеством программ: разработку формализованного описания качества и его
измерений, нахождение низкокачественных программных компонентов,
выработку действий по оптимизации качества программы, отслеживание и
оперативное реагирование на выходы показателей качества за допустимые
пределы на всех этапах разработки программных средств.
38
Основными разработанными в процессе работы над диссертацией
компонентами для оценивания и управления качеством явились:
 многоцелевая математическая модель программных средств и принципы ее
адаптации к задаче управления качеством;
 метод формализованного описания качества программных средств;
 математическая модель измерений качества программных средств;
 метод синтеза модели измерений качества и алгоритм оценивания качества
программных средств;
 метод оценки степени соответствия программного средства типовым
программным решениям;
 математическая модель оптимизации качества программных средств;
 общие принципы и алгоритм управления качеством на этапах создания
программных средств.
Результаты диссертационного исследования составили теоретическую основу
для создания ряда прикладных программ оценивания и управления качеством,
была подтверждена значимость и практическая ценность разработанных моделей,
методов и алгоритмов в процессе использования этих программ при реализации
ряда Государственных опытно-конструкторских работ.
39
СПИСОК ПУБЛИКАЦИЙ ПО ТЕМЕ ДИССЕРТАЦИИ
Монографии.
1. Бураков В.В. Управление качеством программных средств. Монография.
Санкт-Петербургский государственный университет аэрокосмического
приборостроения. 2009. 287 с.
Публикации в ведущих рецензируемых научных журналах, входящих в
Перечень изданий, рекомендуемых ВАК.
2. Бураков В.В. Управление качеством программных средств. //
Информационно-управляющие системы. 2009. №5 с. 43-47.
3. Бураков В.В. Оценка качества программных средств. // Авиакосмическое
приборостроение. 2009. №4. с. 28 – 33.
4. Бураков В.В. Система управления качеством программных средств. //
Авиакосмическое приборостроение. 2009. №5. с. 27-31.
5. Бураков В.В. Модели и алгоритмы в задачах управления качеством
программных средств на примере приложения для военной телемедицины.
// Мехатроника, автоматизация, управление. Управление и информатика в
авиакосмических системах. 2009. №5. с. 33-36.
6. Бураков В.В. Модель качества программных средств. // Информационноуправляющие системы. 2009. №2. с. 75-78.
7. Бураков В.В., Кузин В.А. Способ автоматизации процесса рефакторинга. //
Информационно-управляющие системы. 2009. №3. с. 40-44.
8. Бураков В.В. Формальный базис оценки качества программных средств. //
Известия вузов. Приборостроение. 2009. №1. с. 15-19.
9. Бураков
В.В. Способы
формальной
спецификации
принципов
проектирования программных средств. // Информационно-управляющие
системы. 2008. №5 с. 22-25.
10.Бураков В. В. Концептуальное моделирование качества программных
средств // Авиакосмическое приборостроение. 2008. № 7. с. 54–60.
11.Бураков В. В. Формализация принципов проектирования программных
средств // Авиакосмическое приборостроение, 2008, № 8. с. 13–18.
12.Бураков В. В. Методика оценки качества программных средств // Известия
вузов. Приборостроение. 2008. Т. 51, № 1. с. 35–41.
13.Бураков В. В. Формальный базис преобразований программных средств //
Известия вузов. Радиоэлектроника. 2008. Вып. 2. с. 22-30.
14.Бураков В. В. Методика преобразования программных средств // Известия
вузов. Радиоэлектроника. 2008. Вып. 3. с. 20-31.
15.Бураков В.В. Методика управления качеством документации авиационного
программного обеспечения // Авиакосмическое приборостроение. 2005. №1.
с. 28 – 34.
16.Бураков В.В. Формализация процесса преобразований программного
обеспечения // Мехатроника, автоматизация, управление. Управление и
информатика в авиакосмических системах. 2006. № 11. с. 19 – 24.
17.Бураков В.В. Моделирование и синтез программной документации //
Вестник молодых ученых. 2002. № 9. с. 68 – 74.
40
18.Бураков
В.В.
Прототип
системы
автоматизации
процессов
документирования // Вестник молодых ученых. 2003. № 3. с. 73 – 79.
19.Бураков В.В., Фильчаков В.В. Методика автоматизации процессов
разработки проектной документации в приборостроении // Известия вузов.
Приборостроение. 2002. № 1. с. 7-14.
Публикации в других печатных изданиях.
20.Бураков В.В., Жаков В.И., Фильчаков В.В., Метод генерации проектной
документации на основе диаграмм потоков данных // Информационные
технологии поддержки принятия решений. Апатиты: КНЦ РАН. 1998. с. 6879.
21.Бураков В.В. Метод автоматизации документирования функциональных
свойств программных систем // 6-ая Международная научно-техническая
конференция студентов и аспирантов. Тезисы докладов том 1., М.: МЭИ,
2000. с. 255-256.
22.Бураков В.В., В. В. Фильчаков, В. И. Путилов. Программирование. //
Апатиты, Кольский Государственный Университет. 2000. 98 с.
23.Бржезовский А.В., Бураков В.В. Автоматизация документирования
программного обеспечения на базе XML-технологий // Модели социальных,
технологических и образовательных процессов. Апатиты: КНЦ РАН. 2001.
с. 39-50.
24.Бураков В.В. Математические основы программных систем. СанктПетербург: Изд-во ГУАП. 2003. 28 с.
25.Бураков В.В. Объектно-ориентированное программирование. СанктПетербург: Изд-во ГУАП. 2004. 62 с.
26.Бураков В.В. Шаблоны объектно-ориентированного проектирования
программ. Санкт-Петербург: Изд-во ГУАП. 2004. 87 с.
27.Бураков В.В. Подход к оценке качества проектной документации
программного обеспечения. Санкт-Петербургский государственный
университет
аэрокосмического приборостроения. Санкт-Петербург.
Рукопись депонирована в ВИНИТИ. 2004. № 1182-В2004.
28.Бураков В.В., Устюхин Н.В., Ковригин Д.А. Применение телемедицинских
технологий в медицинской службе Вооруженных Сил Российской
Федерации // Медицина и высокие технологии 2006 г. № 1. 11 стр.
29.Бураков В. В. Программное средство анализа кода для рефакторинга //
Федеральное агентство по образованию. ФГНУ «Государственный
координационный совет информационных технологий». Отраслевой фонд
алгоритмов и программ. Свидетельство об отраслевой регистрации
разработки № 10143, номер государственной регистрации 50200800552,
Москва. 2008.
30.Бураков В. В. Программное средство автоматизации пользовательского
рефакторинга // Федеральное агентство по образованию. ФГНУ
«Государственный координационный совет информационных технологий».
Отраслевой фонд алгоритмов и программ. Свидетельство об отраслевой
41
регистрации разработки № 10144, номер государственной регистрации
50200800553. Москва. 2008.
31.Бураков В.В. Программное средство детектирования дефектов кода //
Федеральное агентство по образованию. ФГНУ «Государственный
координационный совет информационных технологий». Отраслевой фонд
алгоритмов и программ. Свидетельство об отраслевой регистрации
разработки № 10145, номер государственной регистрации 50200800554.
Москва. 2008.
32.Бураков В.В. Программное средство метрического анализа кода //
Федеральное агентство по образованию. ФГНУ «Государственный
координационный совет информационных технологий». Отраслевой фонд
алгоритмов и программ. Свидетельство об отраслевой регистрации
разработки № 10146, номер государственной регистрации 50200800555.
Москва. 2008.
33.Бураков В.В. Программное средство оценки качества программ //
Федеральное агентство по образованию. ФГНУ «Государственный
координационный совет информационных технологий». Отраслевой фонд
алгоритмов и программ. Свидетельство об отраслевой регистрации
разработки № 10147, номер государственной регистрации 50200800556.
Москва. 2008.
34.Бураков В.В. Программное средство рефакторинга моделей программ //
Федеральное агентство по образованию. ФГНУ «Государственный
координационный совет информационных технологий». Отраслевой фонд
алгоритмов и программ. Свидетельство об отраслевой регистрации
разработки № 10148, номер государственной регистрации 50200800557.
Москва. 2008.
42