CC BY
57
А.И. Долженко
ОЦЕНКА КАЧЕСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ПРОГРАММНЫХ ПРОДУКТОВ
При моделировании и проектировании информационных систем (ИС) важной задачей является обеспечение требуемого качества проектных решений. Для оценки качества объектноориентированных (00) моделей ИС их программной реализации необходимо определить метрики (показатели), которые должны контролироваться на всех этапах жизненного цикла ИС: анализа, проектирования, разработки и развертывания системы. Существенное влияние на качество 00 информационных систем оказывают следующие характеристики: способы абстрагирования объектов, локализация, инкапсуляция, наследование и полиморфизм [1, 2, 3, 4].
Способы абстрагирования позволяют выделить существенные характеристики ИС без учета второстепенных деталей. Это позволяет четко определить концептуальные границы системы с точки зрения потенциального пользователя. Базовой абстракцией объектноориентированного подхода является класс, который может быть представлен на различных уровнях детализации различными способами. 0бъектно-ориен-тированные метрики абстрагирования должны представлять абстракции в терминах измерений классов.
Локализация фиксирует способ группировки информации в программе и системе. В объектно-ориентированных системах информация группируется внутри классов или объектов. Класс представляет собой совокупность объектов, имеющих общие свойства и методы. Атрибуты и методы класса рассматривают как его свойства, так и обязанности соответственно. Атрибуты представляют обязанность знания чего-либо о классе, а методы - обязанности действия, то есть выполнения опреде-
ленных функций. Так как базовым элементом объектно-ориентированной информационной системы является класс, метрики локализации должны применяться к классу или объекту.
Инкапсуляция характеризует процесс разделения устройства объекта и его поведение. При этом структуры данных и элементы реализации методов объектов являются невидимыми для других объектов в системе. Доступ к состоянию объекта осуществляется через его интерфейсные методы или интерфейсы. При этом интерфейсы рассматриваются как общедоступные обязанности. Некоторые методы объекта могут быть скрыты за интерфейсом -закрытые методы. Метрики учета инкапсуляции должны учитывать, с одной стороны, сложность класса, а с другой стороны - способность его взаимодействия с другими классами.
Наследование представляет собой частный случай структурной взаимосвязи между классами, в котором реализуются идеи специализации и абстракции. Дочерний класс наследует свойства и обязанности родительского класса и предполагает его специализацию путем добавления специфичных атрибутов и методов. Наследование распространяется через все уровни иерархии классов. Метрики наследования характеризуют эффективность программной системы в части повторного использования классов и адаптации их к изменяющимся условиям применения.
Полиморфизм позволяет обеспечить возможность абстрагирования общих свойств информационной системы. Это реализуется путем переопределения функциональности методов, что обеспечивает специализацию классов в иерархии наследования.
Широко известными метриками для объектно-ориентированных систем являются метрики Чайдембера (Chidam-ber S.R.) и Кемерера (Kemerer C.F.), которые ориентированы на классы [5]:
- вес методов классов - WMC (weighted methods per class);
- глубина дерева наследования DIT (depth of inheritance);
- количество потомков - NOC (number of children);
- связывание между объектами CBO (coupling between object);
- отклик класса RFC (response for a class);
- низкое зацепление методов LCOM (lack of cohesion in methods)
Вес методов классов - сумма значений статической сложности класса, которая является внутренней метрикой класса и вычисляется по следующей формуле:
WMC = £сг.,
i=1
где ct, i = 1, n - сложность i-го метода класса.
Для оценки сложности метода класса может быть применена циклома-тическая сложность по Мак-Кабу [6]. Цикломатическая сложность - метрика программного обеспечения, которая обеспечивает количественную оценку логической сложности программы. Цикломатическая сложность определяет: количество независимых путей в базовом множестве программы; верхнюю оценку количества тестов, которое гарантирует однократное выполнение всех операторов. Независимым называется путь, который вводит новый оператор обработки или новое условие. Для представления программ используется потоковый граф, который характеризуется следующим:
- граф отображает управляющую структуру программы, в которой закрывающиеся скобки условных опе-
раторов и операторов цикла рассматриваются как отдельные операторы;
- вершины потокового графа соответствуют линейным участкам программы и могут включать один или несколько операторов программы;
- дуга потокового графа является ориентированной и отображает поток управления в программе;
- различаются операторные и предикатные вершины. Из операторной вершины выходит одна дуга, а из предикатной - две дуги;
- предикатные узлы соответствуют простым условиям в программе. Составное условие программы, которое включает один или несколько логических операторов, отображается в несколько предикатных узлов;
- замкнутые области, образованные дугами, называются регионами;
- окружающая граф среда рассматривается как дополнительный регион.
Пример 1. Построить потоковый граф для метода ModifiedAgreement( ), который модифицирует данные в базе данных MS SQL Server 2000. Код данной программы и всех последующих примеров написан на языке C#, взаимодействие приложения с базой данных реализуется с использованием технологии ADO.NET [7].
// Модификация таблицы базы данных Agreement
private void ModifiedAgreement( )
{
1 DataTable ds1 = dsAgreement1.Agreement.GetChanges(Da taRowState.Modified);
2 if(ds1 != null)
3 try
{
4 this.daAgreement.Update(ds1);
5 this.dsAgreement1.Agreement. AcceptChanges(); }
6 catch(Exception x)
{
З9
7 this.dsAgreement1.Agreement. Яе]ес1:СЬа:^е8();
8 MessageBox.Show («Ошибка обновления базы данных данных Agreement»+x.Message, «Предупреждение»); }
}
На листинге программы помеченные операторы соответствуют вершинам графа. На рис. 1 приведен потоковый граф метода ModifiedAgreement.
Цикломатическая сложность вычисляется одним из трех способов:
1. Равна количеству регионов потокового графа.
2. Вычисляется по формуле: V(О) = Е - N + 2, где Е - количество дуг, N - количество вершин графа.
3. Вычисляется по формуле:
V (О) = р +1, где р - количество предикатных вершин в графе.
Рис. 1. Потоковый граф метода.
Для примера 1 вычислим цикло-матическую сложность каждым способом:
1. Потоковый граф имеет 4 региона (Я1, Я2, Я3, Я4);
2. ¥(Є) = 10 дуг - 8 вершин + 2 =
4;
3. У(Є) = 3 предикатных узла + 1
= 4.
Расчеты показывают, что цикломатическая сложность метода Моёь fiedAgreement равна четырем.
При цикломатической сложности программного компонента более 5-8 могут возникнуть сложности с пониманием программного модуля, возрастает риск ошибок, и усложняется процесс модификации и тестирования. В этом случае целесообразно проведение улучшения кода программного компонента, то есть использование рефакторинга [8]. После проведения рефакторинга сложность методов класса становится сопоставимой и может быть принята равной единице. В таком случае метрика WMC оценивает количество методов в классе.
Количество методов и их сложность являются показателями, характеризующими затраты на реализацию и тестирование классов. С ростом количества методов в классе его применение становится все более специфическим, ограничивая возможности повторного использования. Поэтому для классов, предполагающих повторное использование, метрика WMC должна иметь разумно низкое значение.
В упрощенной версии метрики (ci=1) подсчет количества методов в классе можно проводить следующим образом:
1. Подсчитываются только методы текущего класса без учета унаследованных методов. Обоснование целесообразности такого подхода состоит в том, что унаследованные методы уже учтены в родительских классах.
2. Подсчитываются все методы, определенные в данном классе и все унаследованные методы.
3. Подсчитываются текущие методы класса и методы, прямо унаследованные от родителей, так как поведение дочернего класса наиболее сильно зависит от специализации родительского класса.
4. Подсчитываются текущие методы класса и методы, переопределенные в дочернем классе.
На наш взгляд, целесообразно использовать ещё один метод подсчета, учитывающий переопределение методов в дочернем классе.
Метрика ЖМС дает относительную меру сложности класса. Существуют рекомендации по сложности методов. Например, Лоренц [9] считает, что средняя длина метода должна ограничиться 24 строками для языка С++. Считается, что класс, имеющий максимальное количество методов среди классов одного с ним уровня, является наиболее сложным, специфичным для конкретного приложения и имеет наибольший риск в части возможных ошибок.
Глубина дерева наследования - межклассовый показатель, который определяет максимальную длину цепи специализаций или расстояние от корня дерева до класса (листа графа), когда он рассматривается как показатель класса, а не системы.
Пример 2. Иерархия классов представлена на рис. 2. Необходимо определить глубину дерева наследования.
Для иерархии классов метрика Б1Т = 3. Соответственно для отдельного класса Б1Т это длина максимального пути от данного класса до корневого класса в иерархии классов. Так, для класса С211 В1ТС211 =3, а для класса С12 - В1ТС12 =2.
По мере роста Б1Т классы нижнего уровня будут наследовать все больше и больше атрибутов и методов.
Это может привести к трудностям в предсказании поведения класса.
Как отмечается в [3], высота иерархии классов (большое значение DIT) приводит к большой сложности проекта, так как означает привлечение большого количества методов и классов.
Вместе с тем большое значение DIT подразумевает, что многие методы могут использоваться многократно. По нашему мнению, это утверждение не является очевидным, так как в существующих инструментальных системах, например, Microsoft Framework .Net создаваемая в приложении экранная форма наследует от базового класса множество свойств и имеет DIT « 7 , но это не приводит к трудностям в понимании поведения класса. В экономических информационных системах, то есть приложениях экономического характера, имеет смысл анализировать показатель DIT для пользовательской иерархии классов, без учета иерархии библиотеки классов, которая предоставляется инструментальной средой. С учетом сделанного замечания, если на рис.
2 классы С, С1 и С2 включены в общедоступную библиотеку, то для пользовательской иерархии классов DlT = 2, а DlTс12 =1. Такая модификация метрики DIT будет реально отражать проектную сложность иерархии классов разрабатываемой системы.
Рис. 2. Иерархия наследования классов.
Количество потомков NOC характеризует количество подклассов (дочерних классов), которые непосредственно подчинены суперклассу (родительскому классу). Значение NOC соответствует количеству непосредственных наследников класса в иерархии классов. На рис.2 класс С2 имеет два дочерних класса С21 и С22, то есть NOCC2 = 2. Увеличение значения NOC способствует возрастанию в проекте доли повторного использования классов.
В отношении метрики NOC следует сделать замечание относительно её вычисления, аналогичное уточнению метрики DIT. Количество потомков в проектах информационных систем целесообразно оценивать только для пользовательских классов, не рассматривая структуру библиотечных классов. Это объясняется тем, что для конкретной организации важен показатель повторного использования разрабатываемых в проектах классов, а не библиотечных классов, что является вполне естественным методом проектирования в конкретной инструментальной среде, например, библиотеки классов платформ J2EE [10] или Framework .NET [11].
Метрики DIT и NOC характеризуют структуру классов информационной системы. Для хорошо структурированной информационной системы, с учетом ранее сделанных замечаний по их вычислению, иерархия пользовательских классов по вертикали должна быть не более, чем 5 ± 1 уровней и по горизонтали не шире, чем 5 ± 2 ветвей.
Связывание между объектами CBO - мера связанности структур, которая все взаимодействия классов (ассоциация, агрегация, композиция) рассматривает как обмен сообщениями. Связывание характеризует методы данного класса, которые используют методы или свойства другого класса. Увеличение значения CBO снижает способность класса к повторному использованию, а кроме того усложняет его модификацию и тестиро-
вание. Снижение СВО улучшает модульность и повышает инкапсуляцию информационной системы.
Пример 3. Диаграмма классов с ассоциативной связью представлена на рис.3. Необходимо определить связывание между объектами.
Рис. 3. Диаграмма ассоциации классов
Метрики связывания между объектами классов имеют следующие значения: CBOclassl = 2, CBOclass2 = 0, CBO-
class3 0
Большое значение CBO усложняет модификацию и тестирование класса, что повышает чувствительность информационной системы к изменениям. Модульность и инкапсуляция системы улучшаются при уменьшении CBO. Это определяет требование для каждого класса иметь минимально возможное значение CBO.
Отклик класса RFC характеризует меру структурного взаимодействия класса с другими классами. Отклик класса определяется как сумма методов данного класса и методы других классов, вызываемых из данного класса.
Пример 4. На рис. 4 приведена диаграмма классов. Главная форма Form1 посредством меню вызывает дочернюю форму FormCitizen, используя метод Show( ) формы FormCitizen. Необходимо определить отклик класса.
Для класса Form1 метрика RFC=3, так как этот класс имеет два собственных метода (menuCitizen Click, menuExit_Click) и использует один метод (Show) класса FormCitizen.
Form1 FormCitizen
О mainMenul : MainMenu OmenultemCitizen : Menultem <^menultemExit : Menultem ♦Show() ^>Display() (^New() HEditO ^Save()
^menuExit_Click() ^menuCitizen_Click()
menuCitizen_Click(object sender, System.EventArgs e) {
FormCitizen FCitizen;
FCitizen = new FormCitizen();
FCitizen.MdiParent = this;
FCitizen.Show;
}
Рис. 4. Диаграмма классов.
Для класса FormCitizen метрика RFC=5 , так как этот класс имеет пять собственных методов (Show, Display ,New, Edit, Save), а методы других классов не использует.
Низкое зацепление методов LCOM позволяет оценить неперекры-вающиеся наборы переменных экземпляров, используемых методами класса. Если класс содержит m методов {Mi} и a атрибутов {Aj}, то a{M} - количество атрибутов, к которым имеет доступ {Mi} методов, и m{Aj} - число методов, которые имеют доступ к {Aj} атрибутам. С учетом введенных обозначений для зацепления имеем следующую формулу:
LCOM =
- Im(Aj)
V a j=1 ,
1 - m
-m
Это определение зацепления ЬСОМ формирует метрику, значение которой возрастает с уменьшением зацепления, метрика нормирована и позволяет различать классы с разным зацеплением. Инкапсуляция характеризуется связанностью методов внутри класса и, следовательно, небольшими значениями зацепления методов ЬСОМ .
Пример 5. Необходимо рассчитать ЬСОМ для класса ^1Ехр, листинг которого имеет следующий вид.
name);
public class ListExp: IComparable
{
private int id; private string name; public int ID
{
get {return id;} set{id = ID;}
}
public string Name {
get{return name;} set{name = Name;}
}
public ListExp( ) {} public ListExp(int i, string s)
{id = i; name = s;}
public int CompareTo(object rhs)
{
ListExp rhsListExp = (ListExp)rhs; return this.name.CompareTo (rhsListExp.
}
}
Данный класс имеет два поля (id, name) и два метода (ListExp (int i, string s), CompareTo (object rhs)). Конструктор по умолчанию (ListExp( )) не учитываем. Следовательно, а=2, m=2, m(id) = 1, m(name)=2 и
2 (1+2)-2
LCOM = 2-----------= 0,5.
1-2
При анализе, проектировании и разработке информационных систем важным является представление пред-
метной области такой совокупностью классов, которая способна упростить описание конкретной сложной системы и обеспечить её гибкость в отображении многообразных и меняющихся во времени бизнес-процессов. Достижение этих качеств во многом определяется культурой и квалификацией разработчиков, их способностью применять типовые архитектурные решения [12] и шаблоны проектирования [13, 14]. Для учета использования в проекте информационной системы типовых архитектурных решений и шаблонов проектирования целесообразно ввести дополнительную метрику - коэффициент использования шаблонов ЫРАТ, которая вычисляется по следующей формуле:
N ЫРАТ = —ра-, N
где Npat - количество классов информационной системы, используемых в составе типовых архитектурных решений и шаблонов проектирования; N
- общее количество классов информационной системы.
Коэффициент использования шаблонов в проектах является характеристикой качества проекта информационной системы, и его желательно иметь не менее, чем 0,5.
Выводы. Рассмотренные метрики и примеры их вычисления позволяют оценить качество информационной системы на основных этапах её жизненного цикла (анализа, проектирования и разработки) с точки зрения реализации концепций объектно-ориентированного подхода.
Библиографический список
1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд./Пер. с англ. - М.: «Издательство Бином», СПб.: «Невский диалект», 2001.
2. Грэхем И. Объектно-ориентированные методы. Принципы и практика: Пер. с англ. М.: Издательский дом «Вильямс», 2004.
3. Орлов С. А. Технология разработки программного обеспечения. Учеб. пособие. СПб.: Питер, 2003.
4. Мюллер Р. Дж. Базы данных и UML. Проектирование: Пер. с англ. М.: Издательство «ЛОРИ», 2002.
5. Chidamber S.R. and Kemerer C.F. A metrics suite for object-oriented design. IEEE Trans. Software Engineering 20, 1994, p.476-493.
6. McCabe J. A complexity measure. IEEE Trans. Software Engineering 2(4), 1976, p.308-320.
7. Постолит А.В. Visual Studio. NET: разработка приложений баз данных. - СПб.: БХВ-Питербург, 2003.
8. Фаулер М. Рефакторинг: улучшение существующего кода: Пер. с англ. СПб.: Символ-Плюс, 2004.
9. Lorenz, M. and Kidd, J. Object-oriented software metrics. Prentice Hall, 1994. 146p.
10. Иванова Е.Б. Java 2, Etterprice Editional. Технология проектирования и разработки. СПб.: БХВ-Петербург, 2003.
11. Чакроборти А., Кранти Ю.,
Сандху Р. Дж. Microsoft® .NET Framework: Разработка профессиональных
проектов: Пер. с англ. СПб.: БХВ-Петербург, 2003.
12. Фаулер М. Архитектура корпоративных программных приложений: Пер. с англ. М.: Издательский дом «Вильямс», 2004.
13. Гамма Э., Хелмс Р., Джонсон Р., Влиссидес Дж. Приемы объектноориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2001.
14. Ларман К. Применение UML и шаблонов проектирования: Пер. с англ.: Учеб. пособие. М.: Издательский дом «Вильямс», 2004.
