Содержание к диссертации
Введение
Глава 1. Анализ метрик, применяемых при оценивании программных средств, и моделей, используемых для определения и вычисления метрик 10
1.1 Основные понятия, используемые при моделировании программных продуктов 11
1.2 Модели проектов и программ 21
1.3 Основные метрики качества и связь метрик с внешними свойствами программ 39
1.4 Задачи диссертационной работы 48
Глава 2. Разработка согласованной системы моделей традиционной и объектно-ориентированной программ для используемых на практике метрик 49
2.1 Обобщенная модель структуры традиционной программы для используемых на практике метрик . 51
2.2 Модель иерархии наследования классов 61
2.3 Модель потока сообщений 70
2.4 Модель взаимодействия компонентов объектно-ориентированного проекта и программы 76
2.5 Выводы к главе 2 85
Глава 3. Создание языка для формального определения внутренних свойств программ в терминах измерительных языковых моделей 86
3.1 Графовые модели программ и формат их представления 87
3.2 Языковые средства для представления графовых моделей программ в терминах измерительных языковых моделей 104
3.3 Метрики программ 127
3.4 Языковые средства для представления метрик программ в терминах моделей программ 135
3.5 Выводы к главе 3 157
Глава 4. Реализация библиотеки метрик 158
4.1 Построение графовых моделей программ по измерительным моделям 158
4.2 Вычисление метрик программ по графовым моделям . 162
4.3 Выводы к главе 4 167
Заключение 168
Литература 170
Приложение 177
- Основные метрики качества и связь метрик с внешними свойствами программ
- Модель взаимодействия компонентов объектно-ориентированного проекта и программы
- Языковые средства для представления графовых моделей программ в терминах измерительных языковых моделей
- Вычисление метрик программ по графовым моделям
Основные метрики качества и связь метрик с внешними свойствами программ
В литературе по измерению программных продуктов представлены сотни метрик проектов и программ, отражающих внутренние свойства таких программных продуктов [2, 17, 36, 62]. Однако, для большинства из них не установлена связь с внешним качеством. В доступных литературных источниках, представляющих результаты специальных исследований, подтверждающих связь метрик с качеством программных средств, представлено семьдесят таких метрик проектов и программ, называемых далее основными метриками качества. На широкое применение таких метрик в практике разработок указывают такие авторитетные специалисты, как Уорен Харрисон, эксперт по сопровождению ПС и тестированию программ, Джон Мунсон, занимающийся проблемами надежности и качества ПО и являющийся одним из редакторов журнала Software Quality Journal, Виктор Бэзили, специалист по технологии программирования и многолетний главный редактор журнала IEEE Transactions on Software Engineering [21, 22, 39]. Среди этих 70-ти ЗО метрик качества являются метриками 00 проектов и программ [41, 62].
Почти все основные метрики качества определяются не на программах, а на их моделях или проектах программ разного уровня абстракции. Все модели, в терминах которых определяются метрики традиционных проектов и программ представлены в параграфе 1.2. Ниже приводятся названия идентифицированных метрик проектов, программ и их компонентов, ссылки на литературные источники, в которых содержатся определения таких метрик для которых на практике подтверждена связь с качеством программных средств, а также установленные на практике связи между внешними свойствами программ и их метриками. Внешние свойства (характеристики) программ и их подсвойства толкуются в терминах стандарта ISO/IEC 9126 (см. 1.1.3).
Ряд свойств качества ПС (т.е. его внешних свойств) может быть установлен по внутренним свойствам программ этого ПС (по-видимому, более корректно следовало бы сказать: "внешние свойства связаны с внутренними") [36]. Практика разработки ПС подтверждает наличие таких связей. Это относится к таким характеристикам как надежность, эффективность, сопровождаемость ПС и их подхарактеристикам.
В данном параграфе приводятся известные из литературы связи внутренних свойств (метрик) проектов и программ с характеристиками и подхарактеристиками качества ПС. 1. Функциональность
Пригодность и правильность. Вообще говоря, не существует метрик программ, которые позволяли бы установить по текстам программ их пригодность и правильность.
Однако, использование динамического анализатора при тестировании программы позволяет получить значения мер покрытия, связанные определенным образом с функциями программы [20], а именно: если часть кода не проверена, то неизвестно, правильна ли она.
Наиболее распространенные меры покрытия таковы (здесь и далее первый столбец содержит названия метрик, второй - ссылку на литературные источники):
Способность взаимодействовать с другими системами, согласованность и безопасность. Для оценивания этих подхарактеристик применяют метод инспекции с использованием "контрольных списков" (checklists) [20], и не существует статических метрик программ для оценки способности взаимодействовать с другими системами, согласованности и безопасности. 2. Надежность.
Завершенность. Практика разработки ПС подтверждает наличие связи завершенности с некоторыми метриками программ. В частности, число ошибок (number of errors) и "коэффициент несоответствий" (failure rate) значительно коррелированы, согласно [17, 21, 31, 42, 49, 55, 56, 57], со следующими метриками
Модель взаимодействия компонентов объектно-ориентированного проекта и программы
Двумя важнейшими аспектами качества проекта "традиционной" программы считается межмодульное сцепление и функциональной прочность модулей [36, Pressman-97]. Для установления мер (метрик) межмодульного сцепления определены многочисленные модели потока информации в программе, и, в частности, схема модульной структуры (modular stracture chart) и граф сцеплений (coupling graph) [36]. Существуют подобные модели и для определения функциональной прочности модулей [35, 36, 60] (хотя они требуют слишком детальной проработки проекта, а потому их широкое применение сомнительно). Аналогично, качество ОО проекта принято связывать со сцеплением между классами и прочностью классов [41]. Однако, принято считать, что между компонентами. ОО проектов и программ существует более "тонкая" связь, чем связь между модулями традиционных программ через параметры или нелокальные данные [76]. Кроме передачи сообщений методами одних классов методам другого класса (т.е. вызова методами одного класса методов других классов), методы одного класса обращаются к полям (переменным) объектов (представителей) других классов и самих классов [26].
Несмотря на использование в практике различных ОО метрик сцепления между классами и прочности классов, в литературе не упоминаются точные модели ОО проектов и программ, на которых могут быть корректно и согласованно определены такие метрики. Ниже в этом разделе определяются три вложенные модели ОО программы, модели взаимодействия компонентов ОО программы, аналогичные схеме модульной структуры и позволяющие однозначно и согласованно определить соответствующие ОО метрики.
Будем называть простейшей моделью взаимодействия компонентов ОО программы такой направленный граф, в котором вершина соответствует классу программы, а дуга между вершинами-классами соответствует взаимосвязи одного класса с другим. В соответствии с общепринятыми традициями будем различать два типа взаимосвязи между классами (relationship between classes) [26, 46]: передачу сообщений методом класса-отправителя методу класса-получателя и обращение метода класса-отправителя (клиента) к полю объекта класса-получателя или самого класса-получателя. При графическом представлении простейшей модели взаимодействия компонентов классов будем изображать классы помеченными вершинами-точками (где метка - имя класса), а взаимосвязи между классами - направленными (от отправителя к получателю) помеченными дугами (метка - тип связи).
Формально определим простейшую модель следующим образом: Вершина {Имя класса) Дуга {Имя класса-отправителя, Имя класса-получателя, Для определения метрик могут использоваться следующие свойства простейшей модели: число пар вершин, связанных хотя бы одной дугой (число пар связанных между собой классов программы), число вершин, в которые входит хотя бы одна дуга, выходящая из данной вершины (интерпретируемое как число классов в программе, к которым имеет доступ ("использует") данный класс [41]); число вершин, из которых выходит хотя бы одна дуга, входящая в данную вершину (интерпретируемое как число классов в программе, имеющих доступ ("использующих") данный класс [41]); число дуг типа обращение к методу, входящих в данную вершину (позволяющее судить о степени сцепления данного класса с другими классами); число дуг типа обращение к полю, входящих в данную вершину (также позволяющее судить о степени сцепления данного класса с другими классами).
Языковые средства для представления графовых моделей программ в терминах измерительных языковых моделей
В подпараграфах 3.1.1 и 3.1.2 уже представлены (мета)модели понятий Вершина графа и Дуга графа. Это позволяет определить обобщенную метамодель графовой модели программы или ее компонента. Метамодель графовой модели :: = {Название модели, Вершина графа, Дуга графа} Потенциально, определенные выше модели позволяют конструировать практически неограниченное множество графовых моделей программ и их компонентов. В [10, 15] рассмотрены реальные, чаще всего используемые на практике типы графовых моделей программ. Поэтому ниже только они и имеются в виду при конструировании "разумной" формы описания этих типов моделей и моделей реальных программ и их компонентов. Название модели ::= Граф вызовов \ Схема модульной структуры \ Граф сцеплений Расширенный граф вызовов \ Модель Чапина \ Граф потока управления в модуле \ Смешанная модель потока данных и управления в модуле \ Граф зависимости переменных Двудольный граф зависимости между входными и выходными переменными I Модель Тсаи-Лопеза структуры данных \ Простейшая модель наследования классов \ Промежуточная модель наследования классов
Полная модель наследования классов Простейшая модель передачи сообщений Полная модель передачи сообщений Простейшая модель взаимодействия 00 компонентов Промежуточная модель взаимодействия 00 компонентов \ Полная модель взаимодействия 00 компонентов Ниже приведено несколько примеров графовых моделей программы, сконструированных в соответствии с полученной метамоделью, но представленных в различных форматах. Первый пример представляет простую и широко используемую модель. Граф вызовов: (Полностью квалифицированное имя компонента; модуль; {разработанный библиотечный}; {корневая концевая \ промежуточная})
Полностью квалифицированное имя компонента; Полностью квалифицированное имя компонента; направленная; передача управления между модулями). Следующий пример представляет модель наследования классов ОО программы. Полная модель наследования классов: (конкретный абстрактный % тип класса %); % Вершина % (Полностью квалифицированное имя класса; класс; % Список атрибутов % {Полностью квалифицированное имя компонента; {общедоступный \ конфиденциальный \ защищенный); {класс представитель) ); % Список методов % {Полностью квалифицированное имя компонента; {общедоступный \ конфиденциальный \ защищенный); {класс представитель); {используемый без изменений расширяемый заменяемый полностью] устраняемый); {процедура функция) )); % Дуга % (Полностью квалифицированное имя компонента; Полностью квалифицированное имя компонента; направленная; {наследование атрибута классом-потомком от класса-предка наследование метода классом-потомком от класса-предка \ переопределение атрибута классом-потомком переопределение метода классом-потомком \ реализация метода в классе-потомке)
Вычисление метрик программ по графовым моделям
Другой набор компонентов, реализующих определенный в главе 3 набор функций над реляционным представлением графовых моделей программ, позволяет получать значения основных метрик качества.
В главе 3 определен набор функций над реляционным представлением графовых моделей программ, позволяющий специфицировать и вычислять определяемые на таких моделях основные метрики качества, используемые на практике. Спецификации основных метрик качества представлены в приложении 3. Такие спецификации также однозначно интерпретируются и достаточно «легко читаются». В частности, эти спецификации метрик были использованы для реализации соответствующих компонентов библиотеки метрик.
На рисунках 4.9, 4.10 представлены результаты измерения некоторой ОО программы Plants по простейшей модели наследования классов ОО программы, представленной выше. Этими результатами являются таблица значений наиболее популярных ОО метрик и распределение одной из метрик, называемой ClassInheritanceDepth для классов одной программы.
Таким образом, разработанная библиотека метрик является компонентом экспериментального рабочего места оценщика программ, позволяющего ему "проделать" весь необходимый для получения значений основных метрик качества программы путь.
В зависимости от того, значения каких метрик представляют интерес для оценщика, будут строится те или иные графовые модели программы или компонентов программы. В частности, при измерении популярной метрики ShepperdUnitFanOut требуется построить простейшую обобщенную модель структуры программы, позволяющую вычислить по ней значения метрики для каждого модуля измеряемой программы. Для метрики ClassInheritanceDepth необходима модель наследования классов программы.
Разработанная библиотека метрик является компонентом экспериментального рабочего места оценщика программ, предоставляющим возможность пользователю увидеть модель оцениваемого компонента программы или всей программы, увидеть таблицу со значениями метрик и текстовое описание интересующей метрики либо ее спецификацию.
Таким образом, реализована библиотека программ построения структурных моделей программ и вычисления на этих моделях метрик качества для использования в среде MS DOS и ОС WINDOWS для IBM PC-совместимых ЭВМ. Эта библиотека является компонентом измерительной среды для исследования методов -и средств языково-ориёнтированного подхода, а также компонентом экспериментального рабочего места оценщика программ. Указанная измерительная среда используется для исследований в ИАПУ ДВО РАН и для обучения студентов в ДВГУ.
