PETROV / INFOSYSTEMS. How to Measure Software Architecture [1.01]
.pdf
ИЗМЕРЯЕМ… АРХИТЕКТУРУ
Качественно Количественно
Соблюдение общих принципов и частных стандартов разработки архитектуры
Распределение намерений и зон ответственности (ср. SRP) между методами и классами
Реализация шаблонов проектирования разного уровня
Степень зависимости классов друг от друга и узость их зон ответственности
(coupling & cohesion)
Гранулярность (granularity), главным образом — интерфейсов
Повторное использование (reuse) элементов архитектуры
Цикломатическая сложность
Соответствие стилю ( %)
Дублирование кода (%)
41
ПРИМЕР МЕТРИКИ: ЦИКЛОМАТИЧЕСКАЯ СЛОЖНОСТЬ
Понятие условной, или цикломатической, сложности (Ц.с.) ПО введено в оборот Томасом Маккейбом-ст. в статье A Complexity Measure (1976) как мера количества линейно независимых путей в исходном коде системы, модуля, функции, метода или класса
Исследования Т. Маккейба, К. Штайн и др. показали, что:
Ц.с. не зависит от размера программы, но зависит от наличия точек ветвления ( точек путей по управляющему графу программы)
Целесообразно ограничивать Ц.с. отдельных элементов ИС (модулей, методов и т.д.) (напр. 10…15)
Ц.с. является оценкой сверху количества тестовых ситуаций для достижения полного покрытия путей в коде, а также оценкой снизу количества путей по соответствующему графу
|
Большая Ц.с. обычно указывает на низкий уровень зацепления, и наоборот |
|||
|
При наличии в функции с графом = |
, , где — |
||
|
вершины, — дуги, единственной точки выхода Ц.с. |
|||
|
функции составляет |
|
|
|
|
= − |
+ |
||
|
||||
42
SONARQUBE: OPEN EJB PROJECT PROFILE
43
SONARQUBE:
C QUALITY PROFILE [SONAR WAY]
MINOR: 'continue' should not be used
int main(int argc, char* argv[]) { int i;
for(i = 0; i < 10; i++) { if(i == 5) {
continue; /* Non-Compliant */
}
printf("i = %d\n", i);
}
return -1;
}
int main(int argc, char* argv[]) { int i;
for(i = 0; i < 10; i++) {
if(i != 5) { /* Compliant */ printf("i = %d\n", i);
}
}
return -1;
} |
44 |
SONARQUBE:
C++ QUALITY PROFILE [SONAR WAY]
MAJOR: An unconditional throw or break statement shall terminate every non-empty switch-clause
switch (x) {
case 0: /* Compliant */ break;
case 1: /* Compliant - empty drop through allows a group */ case 2: /* Compliant */
break;
case 3: /* Compliant */ throw;
case 4: /* Non-compliant - non empty drop through */ a = b;
default: /* Non-compliant - default must also have "break" */
;
}
45
SONARQUBE:
JAVA QUALITY PROFILE [COMMON RULES]
MAJOR: Methods should not be too complex
|
Maximum complexity allowed (Number) |
|
"The Cyclomatic Complexity is measured by the number of (&&, |
||) operators and (if, while, do, for, ?:, catch, switch, case, return, |
|
throw) statements in the body of a class plus one for each |
|
|
constructor, method (but not getter/setter), static initializer, or |
|
instance initializer in the class. The last return statement in |
|
method, if exists, is not taken into account." |
MAJOR: Methods should not have too many parameters
|
Maximum method parameters (Number) |
"A long parameter list can indicate that a new structure should be |
|
created to wrap the numerous parameters or that the method is |
|
|
doing too many things." |
46
СПАСИБО ЗА ВНИМАНИЕ!
Собственные источники
В ходе подготовки семинара использовались:
•материалы лекций А.В. Петрова в НИУ МГТУ им. Н.Э. Баумана по дисциплине «Системная инженерия» (2013).
Контакты
•Академия информационных систем: www.infosystem.ru
Вопросы
47
СПАСИБО ЗА ВНИМАНИЕ!
48
ЧТО ИЗУЧИТЬ [РУС]?
Вольфсон Б. Стратегия сокращения технического долга // Форум технологий Mail.Ru Group, 2012.
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — Питер, 2007. — 366 с.
ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
Гранд М. Шаблоны проектирования в Java. — М.: Новое знание, 2004. — 559 с. Кериевски Дж. Рефакторинг с использованием шаблонов. — Вильямс, 2006. — 400 с.
Ларман К. Применение UML 2.0 и шаблонов проектирования. Практическое руководство. — 3-е изд. — Вильямс, 2013. — 736 с.
Презентация PVS-Studio. URL: http://www.viva64.com/ru/pvs-studio-presentation/
Фаулер М. Рефакторинг: улучшение существующего кода. — СПб.: Символ-Плюс,
2003. — 432 с.
Фаулер М. Шаблоны корпоративных приложений. — М.: ИД «Вильямс», 2010. — 544 с.
49
ЧТО ИЗУЧИТЬ [ENG]? (1 / 2)
Analyzing Code with IntelliJ IDEA. URL: http://www.jetbrains.com/idea/docs/StaticCodeAnalysis.pdf
ANSI-IEEE 1471-2000. Recommended Practice for Architecture Description of SoftwareIntensive Systems.
Brown, W.J., et al. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
(John Wiley & Sons, 1998).
Eclipse CODAN. URL: http://wiki.eclipse.org/CDT/designs/StaticAnalysis Ergin, L. Technical Debt: Do Not Underestimate the Danger.
Foote, B., Opdyke, W. ‖Life Cycle and Refactoring Patterns that Support Evolution and Reuse,‖ First Conference on Patterns Languages of Programs (PLoP’94), Aug. 1994.
Fields, J., et al. Refactoring: Ruby Edition (Addison-Wesley Professional, 2013).
Fowler, M., et al. Patterns of Enterprise Application Architecture (Addison Wesley, 2002).
ISO 25010:2011. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.
ISO/IEC/IEEE 42010:2011. Systems and software engineering — Architecture description.
50