Жукова

Оцена сложности разработки программного обеспечения по объектно-ориентированной модели

Жукова Д.К.

Общая постановка задачи. Контроль качества программного продукта – это "систематические действия, подтверждающие пригодность к использованию программного продукта в целом" [1]. Цель контроля качества – дать количественные меры качества программной системы. Многие традиционные количественные меры непосредственно применимы и к объектно-ориентированным системам.

При рассмотрении методов оценки качества ОО моделей было выявлено, что для того чтобы дать общую качественную оценку всей системе, необходимо сначала измерить отдельные ее параметры. Для этого используются метрики – количественные критерии оценки, которые должны использовать понятия объектно-ориентированных языков программирования.

Для любого программного продукта метрики должны ориентироваться на его уникальные характеристики. С точки зрения метрик выделяют пять характеристик объектно-ориентированных систем: локализацию, инкапсуляцию, информационную закрытость, наследование и способы абстрагирования объектов. Эти характеристики оказывают максимальное влияние на объектно-ориентированные метрики [3].

Локализация фиксирует способ группировки информации в программе. Так как в объектно-ориентированной системе базовым элементом является класс, то локализация здесь основывается на объектах. Поэтому метрики должны применяться к классу (объекту) как к комплексной сущности.

Инкапсуляция – связывание совокупности элементов. В объектно-ориентированных системах инкапсулируются обязанности класса, представляемые его свойствами, операциями и состояниями.

Информационная закрытость делает невидимыми операционные детали программного компонента. Другим компонентам доступна только необходимая информация. Качественные объектно-ориентированные системы поддерживают высокий уровень информационной закрытости. Таким образом, метрики, измеряющие степень достигнутой закрытости, тем самым отображают качество объектно-ориентированного проекта.

Наследование – механизм, обеспечивающий тиражирование обязанностей одного класса в другие классы. Поскольку наследование – основная характеристика объектно-ориентированных систем, на ней фокусируются многие объектно-ориентированные метрики.

Абстракция – это механизм, который позволяет проектировщику выделять главное в программном компоненте (как свойства, так и операции) без учета второстепенных деталей. Класс – это абстракция, которая может быть представлена на различных уровнях детализации и различными способами.

Связность модуля – мера зависимости его частей, это внутренняя характеристика модуля. Чем выше связность модуля, тем лучше результат проектирования.

Анализ последних исследований и публикаций. Анализ существующих программных средств показал, что программного обеспечения, производящего качественную оценку ОО иерархий сложных программных систем, не существует, так как имеющиеся программные средства позволяют лишь проектировать будущую структуру приложения без возможности оценки ее качества. Ниже приведены наиболее популярные на сегодняшний день метрики оценки сложности разработки ПО по ОО модели.

Цикломатическая метрика МакКэйба не является полезной мерой сложности, если ее применить к объектно-ориентированной системе, потому что она не учитывает структуру классов. Однако она применима к отдельным классам и дает представление об их сложности. Она может быть использована для определения тех классов, которые могут содержать наибольшее количество ошибок [4].

Одним из количественных критериев качества программного продукта является количество обнаруженных ошибок. Во время эволюции системы мы учитываем программные ошибки в соответствии с их весом и расположением.

Чидамбер и Кемерер предлагают несколько мер, которые непосредственно применимы к объектно-ориентированным системам [5]:

• – взвешенная насыщенность класса методами (WMC);
• – глубина дерева наследования (DIT);
• – число потомков (NOC);
• – зацепление объектов (CBO);
• – отклик на класс (RFC);
• – недостаток связности в методах (LCOM).

Взвешенная насыщенность класса дает относительную меру его сложности; если считать, что все методы имеют одинаковую сложность, то это будет просто число методов в классе. Вообще, класс, который имеет большее количество методов среди классов одного с ним уровня, является более сложным; скорее всего, он специфичен для данного приложения и содержит наибольшее количество ошибок.

Глубина дерева наследования и число потомков – количественные характеристики формы и размера структуры классов. Хорошо структурированная объектно-ориентированная система чаще бывает организована как лес классов, чем как одно дерево. Выгоднее строить сбалансированные по глубине и ширине структуры наследования.

Зацепление объектов – мера их взаимозависимости. Так же, как и при традиционном программировании, мы стремимся спроектировать незацепленные (то есть слабо связанные) объекты, поскольку они имеют больше шансов на повторное использование.

Отклик на класс – количество методов, которые могут вызываться экземплярами класса. Связность методов – мера насыщенности абстракции. Класс, который может вызывать существенно больше методов, чем равные ему по уровню классы, является более сложным. У класса с низкой связностью можно подозревать случайную или неподходящую абстракцию: такой класс должен, вообще говоря, быть переабстрагирован в несколько классов или его обязанности должны быть переданы другим существующим классам.

Приведем пример. Американские исследователи изучали зависимость между метрическими показателями модели и сложностью реализации программного кода [7]. Ими было выявлено, что наиболее удобными средствами моделирования являются нейронные сети и нечеткая логика. Объединив эти методики вместе, появляется возможность сформировать новый подход к решению поставленной задачи. Появляется нейро-нечеткий метод, который применим для вычисления сложности ОО модели, принятия решений о ее качестве, моделирования и предсказания дальнейшей разработки ПО согласно заданной модели и выявления дальнейших проблем, связанных с разработкой системы.

Для этого исследования использовалась ANFIS (Адаптивная Нейро-Нечеткая Система Вывода), которая способна обучаться наследованным от нейронных сетей свойствам, чтобы корректировать свои параметры.

Типичная структура АННСВ (ANFIS) показана на рисунке 1.

Рисунок 1 – типичная структура Адаптивной Нейро-Нечеткой Системы Вывода

АННСВ состоит из 5ти уровней. На пути от уровня к уровню параметры ОО модели претерпевают определенные изменения. Реализация функций АННСВ встроена в пакет Matlab. Исследователи не ожидают получить хорошо настроенную модель АННСВ в связи с недостатком данных. Однако анализ полученных выходных данных говорит о том, что:

1. Такие метрики, как CBO, RFC, WMC оказывают большее влияние на количество ошибок при дальнейшем написании ПО;
2. Также результаты показали, что 6 основных метрик коррелированны друг с другом.

Исследовав набор данных ОО модели, удалось выявить значение основных метрик по Чидамберу и Кемереру, как индикаторов дальнейших сложностей в разработке ПО.

Достоинства и недостатки существующих методов, актуальность данных исследований. Наверное, самый неудачный способ оценить написание программного продукта это сосчитать количество строк текста программы. Число строк, попавших во фрагмент кода, никак не связано с его завершенностью и сложностью. Как учесть несколько операторов на одной строке и операторы, которые занимают более одной строки и как измерить количество затраченного труда. Такие вопросы не решаются стандартными методами оценки. Такие параметры более подходят для первых поколений языков программирования, они не являются показателями завершенности или сложности объектно-ориентированной системы. Даже выделенные метрики для объектно-ориентированных систем благополучно пережили начальную фазу определения и фактически используются в создании программных продуктов. Это связано с теоретическим и эмпирическим несоответствием показателей программного обеспечения. Ниже приведены основные проблемы, связанные с использованием популярных метрик ОО моделей [6]:

1. Меры не всегда определяются в контексте некоторых явных, четко определенных целей разработчика, в достижении которых должны помогать данные измерения;
2. Даже если цель является явной, экспериментальные гипотезы часто таковыми не являются;
3. Теоретическая проверка правильности меры часто невозможна, потому что оцениваемый атрибут часто сам нечетко определен;
4. Большинство мер никогда не было подчинено эмпирической проверке правильности;
5. В ходе измерений не всегда принимаются во внимание среда или контекст, в котором они будут применены.

Говоря про эмергентные свойства, можно отметить, что среди основных требований к ОО модели они должны присутствовать в абстракциях объектов. Это обусловлено тем, что в процессе её создания с помощью инкапсуляции и/или агрегации абстракция может объединять множество взаимосвязанных объектов. Именно поэтому, характеристики абстракции нельзя свести только к свойствам инкапсулируемых и/или агрегируемых объектов, необходимо рассматривать свойства, появляющиеся в результате взаимодействия составных объектов.

Тем не менее, необходимо отметить, что множество свойств системы (в том числе и эмергентных), которые выбираются для рассмотрения, во многом зависят от задач, решаемых аналитиком. При этом самый важный критерий выбора – функциональная связность компонент, при которой все элементы объектно-ориентированной модели взаимодействуют в достижении определенной цели.

Все это говорит о том, что невозможно абсолютно автоматизировать и усреднить процесс оценки сложности ОО модели, т.к. в каждом конкретном случае необходимо учитывать особенности поставленной задачи и способы ее реализации во взаимодействии отдельных подсистем/классов/подклассов/функций.

Постановка задачи. После ознакомления с современными разработками в области оценки объектно-ориентированных моделей и выявления проблем и недостатков функционирования существующих систем перед нами стоит задача в оценке объектно-ориентированной модели.

Целями оценки качества ОО модели являются:

1. Определить точку, когда необходимо прекратить анализ и проектирование модели и начать реализацию ПО.
2. Повышение качества разрабатываемого ПО.
3. Сокращение времени на разработку ПО.

Качественно оценив ОО модель, мы сможем разработать методы и алгоритмы оценки сложности разработки программного обеспечения по данной объектно-ориентированной модели. Таким образом, можно сформулировать такие задачи:

1. Выделение из изученных критериев оценки ОО модели наиболее актуальных и гибких в применении к различным видам систем.
2. Изучить отображение выделенных параметров на сложности разработки программного обеспечения по ОО модели.
3. Разработать систему оценки сложности разработки программного обеспечения по объектно-ориентированной модели.

Выводы.

Обозначение цели использования модели, и то, на сколько детальной или обобщенной она будет, определяет принципы моделирования в будущем. Среди нескольких альтернатив, разработчик должен будет выбрать, которая из моделей наилучшим образом отражает и решает проектируемую задачу, какая модель наиболее интуитивно понятна, легко расширяема, и удобна в сопровождении.

После того, как определяется начальная версия модели, наступает этап оценки и отладки ее в процессе использования приложений. Таким образом, с введением объектно-ориентированных метрик будет возможным достижение следующих целей:

• – улучшение понимания качества продукта;
• – оценка эффективности процесса конструирования;
• – улучшение качества работы на этапе проектирования.

В данной работе приведен основной метрический набор для оценки объектно-ориентированной модели. Метрические данные обеспечивают обратную связь между разработчиками программного обеспечения и менеджерами компьютерных систем. Анализ и сбор данных может предсказать целесообразность разработки объектно-ориентированной модели. Использование качественных характеристик, основанных на объективном эмпирическом доказательстве, является серьезной и трудоемкой задачей. Поэтому корректировка собственных действий в процессе создания объектно-ориентированных программных продуктов, основываясь на измеримых данных, облегчила бы работу.

Сегодня создание универсального списка однозначных объектно-ориентированных мер и разработка на их основе таких моделей, которые удовлетворяли бы всем языкам программирования во всех средах проектирования, маловероятно. Поэтому меры и модели должны быть определены и исследованы для отдельных подгрупп задач, связанных общими показателями или требованиями к выходным результатам.

Список литературы

1. Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений на С++ // Rational Санта – Клара, Калифорния // перевод с английского под ред. И.Романовского и Ф.Андреева. – глава 7 «Практические вопросы» – 2001.
2. к.т.н. И.М. Слюсаренко, к.т.н. М.Ю Слюсаренко, Системологический подход к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения // Пятнадцатая техническая конференция «Корпоративные базы данных-2010» Москва, http://citforum.ru/programming/case/ooad_systemology/#3
3. Иванов А.Г., Пятницкий А.А, Филинов Ю.Е. Объектно-ориентированный подход технологии программирования – СПб.: Питер, – 2003.
4. Seyyed Mohsen Jamali Object Oriented Metrics (A Survey Approach) // Department of Computer Engineering Sharif University of Technology – 2006.
5. Review of Complexity Metrics for Object Oriented Software Products // International Journal of Computer Science and Network Security, No.11 – November 2008.
6. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес Приемы объектно-ориентированного проектирования. Паттерны проектирования. Издательство Питер, Санкт-Петербург, 2001.
7. An Empirical Validation of Object-Oriented Design Metrics for Fault Prediction, Journal of Computer Science 4 (7): 571-577, 2008.

© ДонНТУ 2010, Жукова Д.К.