Содержание к диссертации
Введение
Глава 1. Моделирование программных средств 10
Элементы теории графов и теории категорий для моделирования 11
программных средств
Многоцелевая математическая модель программного средства 20
Адаптация многоцелевой математической модели программного средства 23
Выводы 30
Глава 2. Описание качества программных средств 32
Существующие модели и стандарты качества программных средств 33
Варианты описаний качества программ 50
Взаимосвязи между показателями качества 52
Адаптация описания качества 56
Области применения стандартизованных описаний качества 57
Классификация подходов к описанию качества 61
Основные недостатки существующих подходов к описанию качества 64
Требования к описанию качества программных средств 65
Формализованное описание качества программных средств 66
Выводы 84
Глава 3. Оценивание качества программных средств 87
Основы квалиметрии программных средств 87
Стандарты оценивания качества программных средств 102
Метрики качества программных средств 111
Метрические пространства 113
Операторы комплексирования 116
Математическая модель измерений качества программных средств 117
Метод синтеза модели измерений качества программных средств 121
Алгоритм оценивания качества программных средств 122
Выводы 132
Глава 4. Оценивание степени соответствия программного средства типовым программным решениям
Метод оценки степени соответствия программного средства типовым 134
программным решениям
Определение целей оценивания 135
Выбор типовых программных решений 135
Задание допуска нарушений типовых программных решений 135
Способы описания типовых программных решений 136
Построение модели программного средства 150
Способы идентификации нарушений типовых программных решений 151
Анализ нарушений типовых программных решений 153
Сравнительный анализ способов описания типовых программных 154
решений
Выводы 155
Глава 5. Оптимизация качества программных средств 157
Преобразования графов 157
Описание преобразований программных средств 175
Математическая модель оптимизации качества программных средств 186
Адаптация модели преобразований программных средств 186
Алгоритм оптимизации качества программных средств 198
Выводы 206
Глава 6. Управление качеством программных средств 208
Адекватность и эффективность разработанных моделей и принципы их 208
практического использования Процессы планирования, обеспечения и контроля 211
качества программных средств
Структура системы управления качеством программных средств 216
Применение методов классификации и кластерного анализа 218
Алгоритм управления качеством программных средств 226
Выводы 232
Глава 7. Апробация моделей, методов и алгоритмов управления качеством программных средств Программное средство анализа кода для рефакторинга 238
Программное средство автоматизации пользовательского рефакторинга 239
Программное средство детектирования дефектов кода 244
Программное средство метрического анализа кода 247
Программное средство оценки качества программ 251
Программное средство рефакторинга моделей программ 256
Результаты практического использования разработанных программных 259
средств
Выводы 262
Заключение 264
Список использованных источников 266
- Адаптация многоцелевой математической модели программного средства
- Формализованное описание качества программных средств
- Задание допуска нарушений типовых программных решений
- Адаптация модели преобразований программных средств
Введение к работе
Компьютерные технологии и программное обеспечение используются на современной стадии развития общества повсеместно. Практически все виды человеческой деятельности, включая потенциально опасные для жизни людей и планеты, доверены программному управлению. В разработку программных средств вовлечено множество людей и организаций, на создание программ расходуются огромные ресурсы. Учитывая эти факты, нет необходимости в доказательстве актуальности и практической значимости исследований в области качества программного обеспечения. В этой области особенно важными представляются проблема формирования общих подходов к оцениванию качества и задача определения общих принципов управления качеством программных средств.
Оценивание качества программного обеспечения является многокритериальным процессом, который объединяет такие действия, как формирование набора критериев, выбор их эталонных значений, измерение фактических значений, сравнение их с эталонными и определение состояния качества программы. В современной практике разработки программ все составляющие процесса оценивания реализуются экспертами, а сформированная в результате оценка качества не всегда является объективной. Выбранные для оценивания критерии носят, в основном, описательный характер, процедура выбора эталонных значений - интуитивная, процессы измерения и сравнения - трудно формализуемые. Для управления процессом разработки программы необходимо осуществлять оценку ее качественного состояния постоянно, набор критериев для оценивания и их эталонные значеия должны изменяться сообразно с прогрессом, достигаемым в разработке. В расчете на одну экспертную оценку трудно обеспечить адаптацию процесса оценивания в соответствии с состоянием разработки непротиворечивым, верифицируемым способом. Существующие стандарты и исследования в области оценивания качества не обеспечивают нужной степени формализации, описывают процессы, связанные с оцениванием качества или в абстрактном, непригодном для непосредственного применения, или в детальном, плохо поддающимся адаптации под конкретные реалии разработки, стиле. Неопределенности и пробелы в формализации качества программ провоцируют субъективность при оценивании их качества экспертами, позволяют вводить в эксплуатацию низкокачественные программные продукты, использование которых может быть экономически невыгодным и зачастую небезопасным. Высокая сложность и ответственность задач, решаемых программами, возможный материальный ущерб и угрозы для жизни людей как следствие их недостаточного качества, делают необходимым формализацию всех составляющих процесса оценивания.
При выявлении несоответствия значений измеренных и эталонных показателей в результате процесса оценивания, необходимо определить корректные изменения структурных и поведенческих свойств программы, которые бы позволили перевести ее из одного качественного состояния в другое. Выявленные рассогласования значений
измеренных и эталонных показателей являются симптомами наличия проблем в структуре и поведении программы. Для того чтобы на основе этой, симптоматической информации можно было бы принять определенные решения о доработке программы, она должна быть правильно интерпретирована. При решении этой многокритериальной задачи важно гарантировать отсутствие побочного эффекта, который состоит в ухудшении значений одних показателей качества в процессе улучшения других. Эта задача, также как и проблема оценивания качества программы, в современной практике разработки программ в основном решается экспертами. Существующие стандарты и исследования проблем качества программного обеспечения не определяют способы использования результатов оценивания. Необходима разработка формализованных моделей связывания качественного состояния программы с подходами к его изменению, строгое описание критериев оптимизации и определение общих принципов управления качеством программ.
Важность задач, решаемых программными средствами и описанные пробелы в современном состоянии программной инженерии, выявляют настоятельную потребность в проведении исследований, направленных на разработку математических моделей, методов и алгоритмов для формализации процессов оценивания и управления качеством программ.
Цель диссертационной работы состоит в разработке обобщенных моделей для оценивания качества программ и формировании общих принципов управления качеством на этапах создания программных средств.
Основные задачи. Для достижения поставленной цели в диссертационной работе решались следующие основные задачи.
-
Систематизация и обобщение основных подходов к описанию качества программных средств.
-
Разработка структуры и методов формализованного описания качества программных средств.
-
Исследование наиболее распространенных принципов оценивания качества программных средств.
-
Разработка структуры и методов адаптации обобщенной модели программных средств к задаче управления качеством.
-
Создание обобщенных принципов оценки качественных состояний программ.
-
Анализ и систематизация существующих подходов к оптимизации структурных и поведенческих свойств программных средств.
-
Разработка общих принципов управления качеством на основных этапах жизненного цикла программных средств.
Методы исследования. При выполнении диссертационных исследований использовались: общие методы системного анализа, общие методы теории программирования, методы теории автоматического управления, методы
математического моделирования, методы функционального анализа, методы теории оптимизации.
Научная новизна выполненных исследований заключается в следующем:
-
Реализован системный подход к исследованию принципов оценивания и управления качеством программных средств.
-
Сформированы основные принципы описания качества программ и предложен метод формализованного описания качества.
-
Выработаны методы оценивания и предложена процедура автоматизированной оценки качества программных средств.
-
Предложены формализованные основы моделирования программ, отвечающих задачам определения и изменения качественного состояния программы.
-
Систематизированы принципы оптимизации качественных состояний программных средств.
-
Определены обобщенные принципы управления качеством, предназначенные для использования на этапах создания программных средств.
Практическая значимость. Выполненные в диссертационной работе исследования формируют теоретический базис для оценки и оптимизации существующих подходов к оцениванию и управлению качеством программных средств, дают основу для создания и развития перспективных автоматизированных систем оценивания и управления качеством программ. Предлагаемые в работе модели, методы и алгоритмы позволяют:
создавать формализованные описания качества программных средств с варьируемой степенью детализации, от концепции - к измерениям с целью итерационного нахождения компромисса между высоким качеством, полнотой реализуемых функций, необходимых временных, денежных, людских и других ресурсов и создания консолидированного взгляда на качество программ с точки зрения заказчиков, разработчиков и пользователей;
формировать каталоги шаблонов формализованных описаний качества и моделей измерений программ, для создания корпоративных, государственных и международных стандартов в области качества программных средств;
разрабатывать каталоги высококачественных и ошибочных архитектурных и проектных программных решений, осуществлять автоматизированную классификацию компонент программы по качественным состояниям;
автоматизировать подготовку и реализацию процессов перевода программного средства из одного качественное состояние в другое;
разрабатывать программные системы онлайнового контроля качественного состояния программных средств на всех этапах их создания;
создавать информационно-управляющие системы автоматизации полного цикла процессов управления качеством программ.
В целом, выполненные в диссертации исследования и разработанные теоретические положения могут квалифицироваться как новое крупное достижение в решении проблем оценивания и управления качеством программных средств.
Основные положения, выносимые на защиту:
-
Многоцелевая математическая модель программных средств и способы ее адаптации к задаче управления качеством.
-
Метод формализованного описания качества программных средств.
-
Математическая модель измерений качества программных средств, метод ее синтеза и алгоритм оценивания качества программных средств.
-
Метод оценки степени соответствия программного средства типовым программным решениям.
-
Математическая модель и алгоритм оптимизации качества программных средств.
-
Общие принципы и алгоритм управления качеством на этапах создания программных средств.
Внедрение результатов. Результаты диссертационной работы использовались при разработке процедур управления проектами и подходов к созданию программ, создании стандартов качества предприятия и разработке специального программного обеспечения для Министерства Обороны Российской Федерации:
в ходе опытно-конструкторской работы шифр «Базикмед» (Государственный контракт от 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 г.г.).
Публикации. По результатам диссертационных исследований опубликована монография, 34 научные статьи, из которых 19 опубликовано в ведущих рецензируемых научных журналах, входящих в Перечень изданий, рекомендуемых ВАК, получено 6 свидетельств на разработки, зарегистрированные в Отраслевом фонде алгоритмов и программ.
Структура диссертации. Диссертация состоит из введения, семи глав, заключения, списка использованных источников и двух приложений. Основной материал диссертации изложен на 275 страницах машинописного текста, содержит 98 рисунков и 43 таблицы. Библиографический список включает 219 наименований.
Адаптация многоцелевой математической модели программного средства
Так как все типы отношений в UML определены как экземпляры подкласса метакласса Relationship, целесообразно рассматривать все эти подклассы (такие как ассоциация или обобщение) в качестве типов ребер. Все остальные подклассы, являющиеся прямыми или косвенными потомками метакласса ModelElement, отображаются на типы вершин. \
На рисунке 5 представлен фрагмент метамодели UML. Множество типов содержит следующие вершины VT= {classifier, interface, class, feature, attribute, operation}, имеются также отношения частичного порядка: classifier у class,
classifier у interface, feature yattribute и feature y operation.
Необходимо обратить внимание на отличия типов в частичном порядке для помеченного типизированного графа от стандартной метамодели UML:
1) в целях упрощения описания, интерфейсы, параметры и исключения для операций, ограничение доступа для атрибутов, операций и ассоциаций, а также виды и роли для ассоциаций не специфицируются;
2) введен тип ребра Instantiation для описания типов атрибутов и значений операций;
3) введен тип ребра Ownership для описания типов атрибутов и значений операций.
Следующим шагом является создание допустимых графов, задающих разрешенные типы отношений между вершинами тех или иных типов.
Допустимый граф для представления диаграмм классов UML. Сравнивая модели на рисунках 5 и 6 необходимо сделать ряд замечаний:
— в допустимом графе подклассы Relationship представляются ребрами, а не вершинами;
— все ограничения на классификаторы или свойства в допустимом графе автоматически наследуются классами, атрибутами и операциями, являющимися подтипами;
— по сравнению с метамоделью UML допустимый граф имеет две особенности: ассоциация относится непосредственно к классу, а не классификатору и не может связывать более двух классификаторов (для обеспечения последнего пришлось бы использовать гиперграфы).
Для примера описания ограничений на структуру диаграмм классов UML, рассмотрим отношение обобщения. На рисунке 7 представлены недопустимые графы, специфицирующие следующие ограничения на корректное описание отношения обобщения:
Адаптация математической модели для программных средств, описанных объектно-ориентированным языком программирования
Рассмотрим этапы адаптации многоцелевой математической модели для описания программных средств, выраженных объектно-ориентированным языком программирования Java. 1.3
Для иллюстрации многоцелевого характера математической модели программного средства некоторые синтаксические возможности Java (например, ссылки this, операторы if, for, модификаторы abstract, public, protected, private, static, final, внутренние классы, нити) не будут подвергнуты моделированию. Сущности программы (такие как классы, поля, методы, параметры методов) представляются вершинами, чьи метки представляют собой пары из имени и типа сущности. Множество VG={In,Cl,Ty,Va,Si,Pa,Bo,Ex} всех возможных типов вершин представлено в таблице ниже. Тело метода (5о-вершина) отделяется от сигнатуры (iSY-вершины) с целью возможности моделировать позднее связывание, в рамках которого одна и та же сигнатура может иметь несколько реализаций. Вершины Во (тело метода) и Ра (формальные параметры метода) имеют пустое имя.
Отношения между программными сущностями (такие как агрегация, наследование, связывание метода, доступ к переменной и вызов метода) представляются с помощью ребер. Метка ребра представляет его тип. Множество E(f={in,li,si,ge,me,ty,pa,ex,co,dy,fo,ac,up,ra) всех возможных типов ребер представлено в таблице 2. Для ребер типа те (принадлежность) метки использоваться не будут.
Формализованное описание качества программных средств
Формализация описания качества основывается на теории категорий. В качестве обоснования выбора именно этого формального аппарата выступают такие свойства теории категорий как:
— возможность использования в качестве универсального средства для описания различных концепций;
— применимость в качестве мощного средства абстракции и обобщения; — простота использования в качестве основы методологических принципов разработки от концепции к реализации;
— возможность построения с помощью теории категорий универсальных конструкций.
С целью унификации и согласованности описаний, в данном разделе приводятся определения основных теоретико-категорных понятий, и дальнейшее их использование в работе будет соответствовать приведенному здесь контексту.
Категория С состоит из класса объектов ОЬ(С) и класса морфизмов Мог(С). Основные свойства категории:
Класс ОЬ(0 называется классом объектов категории С, а класс Мог(С) классом морфизмов. Элемент ф множества Нс(А, В) называется морфизмом из объекта А в объект В и обозначается ф: А — В или Ац В. Отображение ABD называется законом композиции. Элемент о(а, Р) будем обозначать через ар или аР ( а: А - В и р: В — D) и называть композицией последовательных морфизмов аир. Морфизм 1л называется тождественным морфизмом объекта А. Элементы множества Нс(А, В) называются параллельными морфизмами. Выражение ЩА, В) может быть использовано вместо Нс(/4, В).
Определение 26. Морфизм а:А- В называется:
1) изоморфизмом, если найдется Р є Мог(С) такой, что: оф = 1А, ра = \в;
2) (ко)ретракцией, если выполнено Ра = 1В (ар = 1 );
3) моно(эпи)морфизмом, если для любых Р, у є Мог(С) выполняется Ра = уа = р = у (ар = ау = Р = у), если композиции определены;
4) биморфизмом, если а и моно- и эпиморфизм ;
5) (ко)постоянным морфизмом, если для любых р, у є Mor(Q выполняется Ра = уа (ар = ау), если композиции определены.
Определение 27. Категория С называется конкретной, если она изоморфна подкатегории категории множеств Set. Поскольку последняя категория изоморфна подкатегории категории непустых множеств Setn, категория С конкретна тогда и только тогда, когда она изоморфна подкатегории категории Setn. Любая подкатегория конкретной категории конкретна и произведение конкретных категорий является конкретной категорией.
Определение 28. Категория С называется полной, если в ней каждая С-диаграмма имеет предел [83].
Определение 29. Категория С называется кополной, если каждая С-диаграмма имеет копредел [83].
Определение 30. Биполной называется категория, являющаяся одновременно полной и кополной [83].
Определение 31. Конечной диаграммой называется диаграмма, имеющая конечное число объектов и конечное число стрелок между ними. Категория называется конечно полной, если она содержит предел любой конечной диаграммы. Конечная кополнота и конечная биполнота определяются аналогичным образом [83].
Определение 32. Объекты А и В категории С называются связанными, если в С найдется такая конечная последовательность объектов Ао,А\,...,Ап что A=AQ,
В=Ап и Н(Аі_і,Аі) иїі(Аі,Аі+і) 0 для каждого /=0,1,...,л-1. Категория С, в которой каждая пара объектов связана, называется связанной [82]. Определение 33. Категория SubC называется подкатегорией некоторой категории С, если: а) каждый объект категории SubC является объектом категории С; б) каждый морфизм категории SubC является морфизмом категории С; в) единичные морфизмы категории SubC являются единичными морфизмами в С; г) произведение aft морфизмов a,J3eSubC совпадает с произведением этих же морфизмов в категории С. Подкатегория SubC категории С называется полной подкатегорией, если HSubC№,B) = В.с(А,В) для каждой упорядоченной пары объектов А,В є SubC. Определение 34. Множество морфизмов (щ\ A- Aj, ієГ) произвольной категории С с общим началом в объекте А называется конусом с вершиной А. Любое подмножество морфизмов конуса называется подконусом. Двойственным к понятию конуса морфизмов является понятие коконуса морфизмов: коконус морфизмов есть множество морфизмов (щ: А{— А, ієі) с общим концом в объекте Пусть (щ: А В, ієГ) — фиксированный коконус категории С. Конус (/?/:
Х- А(, ієі) называется допустимым относительно коконуса (а/: А В, ієі), если
РІЩ = J3j(Xj для всех ij Gl. Определение 35. Конус (af U- Af iel) называется универсальным относительно коконуса (af Af B, і el), если он допустим относительно этого коконуса и если для любого конуса (/?/: X- Af iel), допустимого относительно коконуса (af Af-bB, iel), существует такой единственный морфизм уг. X — U, что Ві=ац//,ієІ.
Универсальный конус (af U- Af iel) относительно коконуса (af А В, iel) будет обозначаться coun(a/, iel). Все конусы, универсальные относительно данного коконуса (щ, iel), составляют подобъект семейства объектов Af, который обозначается Соші(аг-, iel).
Двойственным образом определяется коуниверсальный коконус относительного некоторого конуса (/?/: А— В/, iel), который будет обозначаться cocoun(/7/, ієТ). Соответствующий факторобъект семейства объектов будет обозначаться Сосоші(/3/, iel) [81].
Рассмотрим теперь частный случай, когда коконус (af Af- B, iel) состоит из двух морфизмов а\: AfB, i=l,2. Если (U; ajt (J2)=co\m(aj, aj), то в силу имеет место коммутативный квадрат
Задание допуска нарушений типовых программных решений
Первый этап метода предполагает формулирование целей предполагаемого оценивания степени соответствия типовым программным решениям. Типичными целями являются:
— оценка качественного состояния ПС;
— проверка соответствия стандарту программирования;
— поиск дефектов, связанных с нарушением того или иного типового решения;
— поиск программных структур, подлежащих рефакторингу.
На втором этапе метода происходит формирование номенклатуры типовых программных решений, на соответствие которым предстоит сертифицировать программное средство. Источником информации этого этапа служит стандарт проектирования программ, принятый на предприятии-разработчике, техническое задание, мнения экспертов по качеству и т.п.
На третьем этапе происходит установка допустимых границ нарушений правил, задаваемых типовыми программными решениями. Этот этап важен для тех случаев, когда целями реализации метода являются получение интегральной оценки качественного состояния ПС или интегрального уровня соответствия используемым стандартам программирования. Значения допусков устанавливают эксперты или происходит использование значений, указанных в стандартах программирования или техническом задании.
Допустимые графы целесообразно использовать не только для описания видов отношений между теми или иными типами программных сущностей, как это было показано в первой главе, но также и для описания типовых программных решений. В этом случае допустимые графы используются не для строгого задания ограничений на возможные виды связей, а для описания структур с определенными свойствами. Ограничений на типы свойств не накладывается, таким образом, допустимые графы служат для описания некоторой информации, которая затем нуждается в интерпретации — качественной оценке.
С помощью допустимых графов могут быть равным образом описаны и эталонные и низкокачественные программные решения. Высококачественные решения, шаблоны проектирования [26, 109], могут быть описаны графами для систематизации знаний о хорошо зарекомендовавших себя программных решениях.
Допустимые графы также могут описывать низкокачественные структуры -дефекты [9] и антипаттерны [108], с целью систематизации ошибок и поиска структур для проведения рефакторинга. На рисунке 54 приведен пример описания низкокачественного программного решения. Типы вершины Va обозначает поле, С/ - класс, а тип ребра mepub используется для обозначения принадлежности поля классу и того, что это поле является общедоступным. Таким образом, приведенный допустимый граф описывает низкокачественное программное решение «нарушение инкапсуляции».
Как уже отмечалось, с помощью ролей вершин графов можно вводить правила проектирования, описывающие типовые ограничения на возможные зависимости программных сущностей. Этим способом можно специфицировать нежелательные с точки зрения качества ПС программные решения. Проиллюстрируем механизм использования ролей и правил на примере шаблонов (типовых решений) в области объектно-ориентированного дизайна. В работах [26, 109] описаны объектно-ориентированные шаблоны проектирования, относящиеся к трем типам, порождающие, структурные, поведенческие и архитектурные. Выберем для иллюстрации формализации типовых программных решений с использованием ролей по одному шаблону каждого типа.
Для того чтобы использовать роли и задавать правила использования ролей, необходимо в коде аннотировать программные сущности идентификаторами ролей. В зависимости от парадигмы программирования и конкретного языка способы аннотации могут быть разными. Для объектно-ориентированной парадигмы варианты для сопоставления ролей с программными сущностями могут быть следующими:
1) Введение собственных тегов или атрибутов
Этот вариант предполагает использование зависящей от языка программирования техники комментирования для введения идентификаторов ролей программных сущностей. Например, для языка Java, спецификация того, что некоторый класс выполняет роли объекта предметной области из архитектурного шаблона «модель-представление-контроллер» и роль субъекта из поведенческого шаблона «наблюдатель», могла бы выглядеть так: SRoles("domainObject, subject") public class Person {...} Спецификация тех же ролей для класса С# использует технику документирования, определенную для этого языка.
Адаптация модели преобразований программных средств
На метрических пространствах Л/ определяются операторы преобразований. Назначение операторов состоит в изменении значений базовых метрик, путем преобразования модели ПС. Во множество таких операторов входят операторы добавления и удаления вершины (ребра) для всех типов вершин и ребер. Определение 120. Базовые операторы преобразований. Базовые операторы преобразований А іА -їМ1 соответствуют элементарным преобразованиям моделей ПС, определяемым базисом Pb={Insertv InsertBDropv,DropE}.
Определение 121. Производные операторы преобразований. Производные операторы преобразований А -.А - М1 соответствуют составным преобразованиям моделей ПС, определяемых композициями условных продукций bHRapc=piP2..Pn-Go- G„.
На основе изложенной теории перезаписи графов и приведенных определений элементарных, составных преобразований сформулируем определение модели оптимизации качества ПС. Определение 122. Математическая модель оптимизации качества программных средств. Модель оптимизации качества программных средств основана на многоцелевой модели программных средств и модели измерений, включает базовые и производные операторы преобразований удовлетворяющие следующим условиям:
— могут быть выражены базисом, который включает морфизмы удаления и добавления ребра и вершины каждого типа;
— существуют инъективные морфизмы из графов левых и правых частей продукций преобразований в каждый из допустимых графов модели ПС;
— не существуют инъективные морфизмы из графов левых и правых частей продукций преобразований в каждый из недопустимых графов модели ПС.
Модели оптимизации качества свойственен обобщенный характер, перед ее использованием для формализации описания преобразований конкретного ПС, эта модель должна пройти стадию адаптации.
Для возможности адаптации модели оптимизации необходимым условием является наличие математической модели этого ПС, в которой определены возможные типы вершин и ребер, а также допустимые и недопустимые графы. Адаптация модели оптимизации включает следующую последовательность действий:
— определение базиса преобразований, состоящего из множества элементарных преобразований удаления и добавления вершины и ребра каждого из допустимых типов, вместе с их пред- и постусловиями;
— синтез составных преобразований - представляет собой экспертную работу, цель которой состоит в упрощении процесса описания преобразований за счет объединения элементарных преобразований в наиболее употребительные составные;
— анализ составных преобразований - проверка согласованности левых и правых частей составных преобразований с допустимыми и несогласованности с недопустимыми графами. Далее рассматриваются примеры реализации этих действий применительно к ПС, выраженных с помощью диаграмм классов UML и объектно-ориентированного кода на Java.
В главе, посвященной описанию многоцелевой математической модели ПС в был приведен пример ее адаптации для описания ПС, заданных диаграммами классов UML. Воспользовавшись этим описанием, опишем преобразования диаграмм классов UML.
В таблице 27 приведен перечень элементарных преобразований UML-диаграмм. Эта совокупность образует базис преобразований. В целях оптимизации процесса преобразований существует возможность пополнения списка элементарных преобразований, например, можно ввести RenameClass за счет использования Renamey или RetypeAttribate с использованием Retypey. Основанием для такого расширения должен послужить анализ целей создания множества преобразований. Каждое из базисных элементарных преобразований UML-диаграмм классов описывается с помощью совокупности соответствующих парадигмонезависимых преобразований, пред- и постусловий.
Синтез составных преобразований в отдельный класс мотивируется частотой применения и концептуальной значимостью этих преобразований. В соответствии с задачами преобразований может быть сформирован тот или иной каталог составых преобразований для ПС, описанных с помощью диаграмм классов UML. Некоторые виды этих составных преобразований представлены ниже. В главе, посвященной адаптации многоцелевой математической модели ПС в качестве примера была описана последовательность действий по ее настройке для описания Java-кода. Напомним некоторые обозначения и продолжим описание в рамках моделирования преобразований используемого в том примере фрагмента кода (см. таблицы 1, 2 и рисунок 10).
Тело метода описывается с помощью структуры, состоящей из Ех-помеченных вершин, соединенных ребрами, представляющих информацию о динамических вызовах, доступах и модификациях переменных. На рисунке 79 представлена структура метода myCreayeTimer класса TimerClassBean.
В таблицах 1 и 2 приведены типы вершин и ребер, соответствующие программным сущностям и их отношениям. Соответственно типам вершин, представленным в таблице 1, в состав базиса преобразований будут входить 8 элементарных преобразований добавления вершины каждого типа и 8 -удаления. Соответственно типам ребер, представленным в таблице 2, в состав базиса преобразований будут входить 24 элементарных преобразований добавления ребра каждого типа и 24 - удаления. Таким образом, базис преобразований для программы на Java коде будет состоять из 64 преобразований.
