Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.

2. РАЗРЕШИТЕ ПРЕДСТАВИТЬСЯ
АЛЕКСЕЙ ПЕТРОВ
тренер и консультант, эксперт-практик в области анализа и
моделирования бизнес-процессов, системного анализа,
архитектуры ПО, проектирования средств и методов
взаимодействия и БД
2013:
докладчик конференций Stratoplan TECH & BUSINESS Summit
(поток «Проектирование и анализ») и DEV Labs C++
2012 — наст. вр.:
преподаватель совместного проекта Mail.Ru Group и НИУ МГТУ
им. Н.Э. Баумана
2012:
участник запуска этапа работ по внедрению системы анализа
оперативных данных на базе SAP BusinessObjects
2011:
автор серии курсов по моделированию бизнес-процессов, БД
и постановке внутренней разработки
2005 — 2011:
участник более 10 проектов внедрения корпоративных ИС,
моделирования бизнес-процессов и ИТ-аудита организаций
2

3. МЕТОДИЧЕСКИЕ
И ОРГАНИЗАЦИОННЫЕ ПОЛОЖЕНИЯ
1
2
3
Цели семинара
Семинар посвящен вопросам качественной и количественной
оценки архитектуры программных систем в целях установления ее
качества, оптимизации процессов разработки архитектуры и
устранения «технического долга» проектов разработки таких систем
Предварительная подготовка
Владение основными элементами одного из рабочих языков
тренинга (C++, Java);
знакомство с проблематикой и каноническими шаблонами
объектно-ориентированного проектирования (GoF, GRASP).
Перспективы
Семинар является вводным и готовит к прохождению тренинга
«Управление качеством объектно-ориентированной архитектуры и
программного кода»
3
НА ВРЕМЯ ПРОВЕДЕНИЯ СЕМИНАРА, ПОЖАЛУЙСТА, ПЕРЕВЕДИТЕ ЛИЧНУЮ ТЕХНИКУ И
СРЕДСТВА СВЯЗИ В БЕЗЗВУЧНЫЙ РЕЖИМ. СПАСИБО!

4. О ЧЕМ ПОЙДЕТ РЕЧЬ?
1
2
3
Архитектура информационной системы
Из чего складывается архитектура ИС и что делает ее разработку
болезненной процедурой?
Архитектура «в малом» и архитектура «в большом»
Почему архитектура — не документ?
«Технический долг»: от причины до
устранения
«Технический налог»
Статический анализ и рефакторинг
программной архитектуры и исходного кода
Модели и атрибуты качества программной архитектуры
Метрики объектно-ориентированной архитектуры и их взаимосвязь
с атрибутами качества
4

5. Договоримся о терминах
Архитектура и ее описание
Место и роль архитектурного
описания в инженерии ПО
Почему архитектура — не документ?
Архитектура «в большом» и «в
малом»
Отдельные метрики ОО-архитектуры
5

6. ДОГОВОРИМСЯ О ТЕРМИНАХ: АРХИТЕКТУРА


ANSI/IEEE 1471-2000
"Architecture is the fundamental organization of a system
embodied in its components, their relationships to each other,
and to the environment, and the principles guiding its design and
evolution"
UML 1.5
"[Architecture is] the organizational structure and associated
behavior of a system. An architecture can be recursively
decomposed into parts that interact through interfaces,
relationships that connect parts, and constraints for assembling
parts. Parts that interact through interfaces include classes,
components and subsystems"

Martin Fowler et al. Patterns of Enterprise
Application Architecture (Addison Wesley, 2002)
"… if you find that something is easier to change than you once
thought, then it's no longer architectural. In the end architecture boils
down to the important stuff—whatever that is"
6

7. МИФЫ И РЕАЛЬНОСТЬ:
АРХИТЕКТУРА И ЕЕ ОПИСАНИЕ
7
1
2
3
Архитектурное описание
Результат деятельности архитектора, отражение
архитектуры системы, основа создания подсистем
Может отсутствовать / существовать в нескольких
вариантах
Цель проектирования архитектуры
Синтез решения, удовлетворяющего требованиям
к системе
Архитектура системы
Основополагающие принципы организации — «все
важное о системе, рассматриваемой в ее связях с
внешней средой» [ISO/IEC/IEEE 42010:2011]
e.g. Составные элементы системы, порядок сборки
(взаимосвязей), принципы организации (дизайна)

8. МЕСТО И РОЛЬ АРХИТЕКТУРНОГО ОПИСАНИЯ
В СОВРЕМЕННОЙ ИНЖЕНЕРИИ ПО
8
Заинтересованные стороны, их интересы,
группы и методы описаний, виды моделей,
модели архитектуры, архитектурные решения и
обоснования объединяются понятием
элемент AD (англ. AD element).
Заинтересованная
сторона
Система Архитектура
Архитектурное
описание (AD)
Внешняя среда
1..*
1
1..*
проявляет интерес к ▼
обладает ►
0..* 0..*
расположена в ▼
0..*
отражает ▼
1..*
0..*

9. ПОЧЕМУ АРХИТЕКТУРА — НЕ ДОКУМЕНТ?
9
Архитектура
системы
Архитектурное
описание≠
❶ Независимо от архитектурного подхода:
«4 + 1», RM-ODP, TOGAF и др.
❷ Независимо от методологии разработки:
DDD, TDD, Scrum и др.

10. ХАРАКТЕРИСТИКИ ПРОГРАММНОЙ СИСТЕМЫ
С ИЗВЕСТНОЙ АРХИТЕКТУРОЙ
10
Границы
и точки
расширения
Внешние
(«пользовательские»)
внутренние
(«архитектурные»)
атрибуты
качества
Бизнес-
метафора
OLAP vs. OLTP
Data vs.
Processes
Архитектурная
метафора
с метриками
дизайна
Components vs.
Services
Sync. vs. Async
Выбранная метафора (стиль)
определяет качественные
и количественные показатели
архитектуры

11. АРХИТЕКТУРА «В БОЛЬШОМ» И «В МАЛОМ»
11
Макро-
архитектура
Микро-
архитектура
КОМПОНЕНТ ПОДСИСТЕМА
СЛОЙ СЛУЖБА ФУНКЦИЯ
АТРИБУТ ЗАДАЧА ИНТЕРФЕЙС
КЛАСС МЕТОД СТРУКТУРА
АБСТРАКЦИЯ ДЕЛЕГИРОВАНИЕ ИНКАПСУЛЯЦИЯ КОМПОЗИЦИЯ НАМЕРЕНИЕ
НАСЛЕДОВАНИЕ ОТВЕТСТВЕННОСТЬ ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ ПОЛИМОРФИЗМ
ГРАНУЛЯРНОСТЬ СВЯЗНОСТЬ ЗАЦЕПЛЕНИЕ
PoEAA
GoF
GRASP

12. ОТДЕЛЬНЫЕ МЕТРИКИ ОО-АРХИТЕКТУРЫ
12
1
2
3
Зацепление (cohesion)
Описывает нацеленность, сфокусированность
архитектурного элемента на решении задач в
рамках одной зоны ответственности (ср. SRP –
Solid Responsibility Principle)
Гранулярность (granularity)
Характеризует способ реализации архитектурным
элементом (напр. интерфейсом) намерения
(intention), вмененного ему разработчиком
Связность (coupling)
Отражает взаимозависимость архитектурных
элементов (напр. классов) по данным или по
управлению

13. ВОПРОС #1
13
ИЗВЕСТНЫ ЛИ ВАМ ПРИМЕРЫ ПРОЕКТОВ С
ИДЕАЛЬНОЙ АРХИТЕКТУРОЙ?
НЕОБХОДИМОСТЬ ПЕРЕСМОТРА АРХИТЕКТУРЫ —
СИГНАЛ TECHNICAL_DEBT

14. Знакомьтесь!
Принятие «технического долга»
Когда можно брать «технический
долг»?
Признаки чрезмерного долга
Стратегии снижения долга
Личный опыт (2004 – 2014)
14

15. ЗНАКОМЬТЕСЬ!.. «ТЕХНИЧЕСКИЙ ДОЛГ»
15
Уорд
Каннингем
1992
Назначение метафоры
возможность обсуждения
«неправильной разработки» с
заинтересованными сторонами
нетехнического профиля
1
2
Содержание
временные архитектурные решения
устаревающие и устаревшие
технологии
ошибки и «мертвый» код
нереализованные тесты
невыполненные работы по
рефакторингу продукта
Опасность
выплата «технического долга» стоит
денег, времени и усилий со стороны
разработчиков и заинтересованных
сторон
3

16. ПРИНЯТИЕ «ТЕХНИЧЕСКОГО ДОЛГА»
16
«Да» «Нет»
 Краткосрочное ускорение разработки
 Утрата гибкости и усложнение
изменений
 Рост затрат спонсоров
 Неконтролируемый и «грязный» код
низкого качества
 Чрезмерная специализация
разработчиков
 Возможное «техническое банкротство»
— неизбежная потребность в полном
переписывании продукта
 Замедление разработки
 Упрощение будущих изменений,
гибкость продукта
 Поддержание качественной кодовой
базы и качественного дизайна
 Отсутствие затрат времени на
изучение и рефакторинг кода
 Отсутствие «технической инфляции» —
технологического отставания от
индустрии

17. КОГДА МОЖНО БРАТЬ «ТЕХНИЧЕСКИЙ ДОЛГ»?
17
1
2
3
Быстрая отгрузка системы
… важнее «чистого» кода («исправим позднее»)
e.g. Близость релиза; реакция на изменения
законодательства
«Одноразовый» код
… принципиально не требует выплат долга
Стратегическое видение дизайна
… позволяет ценой долга получить оперативный
отклик заказчика и сформировать требуемый
дизайн
e.g. Стремление захватить рынок

18. КОГДА МОЖНО БРАТЬ В ДОЛГ: ГРАФИК
18
Сложность
архитектуры
Функциональные
возможности
𝑥0
❶ Стратегическое
видение
𝑓0
𝑓1
𝑥′
𝑥′
′
Хорошая новость
значение 𝒙 𝟎 существует
1
2
Плохая новость
никто не знает, где
𝒙 𝟎 расположена
Удачная архитектура
Неудачная архитектура
𝑥′′ − 𝑥′ — долг
Мартин
Фаулер

19. ПРИЗНАКИ ЧРЕЗМЕРНОГО ДОЛГА
19

Дублирование кода и нечитаемый код
Нарушают принципы ОО-проектирования DRY [Don’t Repeat
Yourself] (ср. Single Point of Maintenance) и SCP [Speaking Code
Principle]
Ведут к аномалиям обновления и маскировке истинных целей,
проблемам понимания кода и заставляют разработчиков тратить
больше времени на чтение, чем это необходимо
Панический страх изменений
Добавление новых функций с каждым разом стоит
только дороже
Проблемный дизайн
Содержит «обходные пути» и побуждает к «трюкам»
при разработке
Зависит от знаний одного разработчика
Реализован в коде с множеством пометок на
доработку и исправление
Неверный выбор технологий и библиотек
Предпочтение должно отдаваться новейшим, зрелым и наиболее
«дешевым» в модификации технологиям
ПО устаревает и со временем влечет накопление долга




20. СТРАТЕГИИ ПОГАШЕНИЯ ДОЛГА
20
1
2
3
«Технический налог»
 Эффективное распространение знаний
 Сложность планирования и расстановки
приоритетов
Выплата долга
Основной объем — рефакторинг
Проценты — время, потраченное не на написание
кода
Выделенная команда
 Удобство управления ресурсами и планирования
 Слабость в передаче знаний об архитектуре и коде
 Нарастающая психологическая усталость

21. ТЕХНИЧЕСКИЙ ДОЛГ: ЛИЧНЫЙ ОПЫТ
21
1
2
«Технический налог»
Расширенные технические советы
Энтузиазм разработчиков
Оптимально — 1 день в 2 недели (один и тот же,
если позволяет план-график) или в спринте
Продуктовая разработка
Проекты с длительным циклом разработки рано
или поздно всегда переписываются «с нуля»
10%

22. ВОПРОС #2
22
ДОБИТЬСЯ УЛУЧШЕНИЯ АРХИТЕКТУРЫ
НЕВОЗМОЖНО, ЕСЛИ НЕ НАЧАТЬ УЛУЧШЕНИЕ
АРХИТЕКТУРЫ. С ЧЕГО НАЧАТЬ?
CODE_INSPECTION && DESIGN_REVIEW
КАК ЧАСТЬ ИНЖЕНЕРНОЙ КУЛЬТУРЫ

23. Статический анализ исходного кода
Пересмотр кода как метод
персональной оценки
Рефакторинг и правила ОО-
проектирования. Примеры
Эффективность статического
анализа кода и пересмотров
архитектуры
Инструменты статического анализа
23

24. СТАТИЧЕСКИЙ АНАЛИЗ ИСХОДНОГО КОДА
24
1
2
Что выявляет?
Неверное или неопределенное поведение кода
Вызов методов как процедур
Нарушение зон ответственности классов и т.д.
Как и когда?
Предшествует рефакторингу и сопровождает его
Проводится без реального выполнения кода,
вручную или специальными инструментами
3
Персональная оценка (инспекция)
Статический анализ без использования инструментальных средств
в целях определения качества кода с позиции:
• эффективности (использования ресурсов, вычислительной сложности);
• удобства сопровождения (анализа, проверки, внесения изменений);
• надежности (зрелости, способности к восстановлению после сбоев) ;
• прочих структурных показателей качества (напр. по ГОСТ Р ИСО 9126).

25. ПЕРЕСМОТР (CODE REVIEW)
КАК МЕТОД ПЕРСОНАЛЬНОЙ ОЦЕНКИ КОДА
25
1
2
Рецензенты
Назначение из числа членов команды, не
являющихся первоначальными владельцами кода
Регулярность
Отчет о проведении — на каждом техническом
совете (напр. еженедельно)
3
Вовлечение
Распространение знаний о каждом (не)удачном
фрагменте кода среди всех членов команды
4
Управление
Назначение сроков и ответственных за
исправление выявленных недостатков

26. РЕФАКТОРИНГ АРХИТЕКТУРЫ И КОДА
26
1
2
Улучшение структуры ПО
Облегчение понимания работы кода 
облегчение обнаружения ошибок
Упрощение модификации без изменения
наблюдаемого поведения системы
Улучшение композиции
Технологичность
Систематическая деятельность с предсказуемым
результатом каждого элементарного шага
3
Ускорение разработки
Повышение скорости внесения
изменений и реализации
новых функций
4
Возможности и угрозы
 Продолжение проектирования во время разработки (сопровождения)
 Необходимость модификации работающего кода
и возможного пересмотра интерфейсов (API)

27. ПРИМЕРЫ РЕФАКТОРИНГА (1 / 2, UML)
27
1
Переименование метода
Источник: Мартин Фаулер, Rename Method
Причина: текущий вариант имени не раскрывает
назначение метода.
getinvcdtlmt()
Customer
getInvoiceableCreditLimit()
Customer

28. ПРИМЕРЫ РЕФАКТОРИНГА (2 / 2, JAVA)
28
2
Введение поясняющей переменной
Источник: Мартин Фаулер, Introduce Explaining
Variable
Причина: выражение чересчур сложно для
понимания и поддержки.
if((platform.toUpperCase().indexOf("MAC") > -1) &&
(browser.toUpperCase().indexOf("IE") > -1) &&
wasInitialized() && resize > 0) {
// ...
}
final boolean isMacOs = platform.toUpperCase().indexOf("MAC") > -1;
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE") > -1;
final boolean wasResized = resize > 0;
if(isMacOs && isIEBrowser && wasInitialized() && wasResized) {
// ...
}

29. РЕФАКТОРИНГ ОО-КОДА
И ПРАВИЛА ОО-ПРОЕКТИРОВАНИЯ
Брайан Фут и Уильям Опдайк в работе Life Cycle and Refactoring Patterns that
Support Evolution and Reuse (1995) указали на ряд правил ОО-
проектирования, многие из которых перекликаются с каталогом методов
рефакторинга из книги Мартина Фаулера.
DR1. Use Consistent Names
DR2. Eliminate Case Analysis
DR3. Reduce the Number of Arguments
DR4. Reduce the Number of Methods
DR7. Minimize Access to Variables
DR8. Subclasses Should Be Specializations
DR9. Split Large Classes
DR11. Separate Methods That Do not Communicate
29

30. МИФ О РЕФАКТОРИНГЕ
30

31. ЭФФЕКТИВНОСТЬ СТАТИЧЕСКОГО АНАЛИЗА
31
> 65%
ошибок
совокупная эффективность
пересмотров дизайна и
инспекции кода иногда
превышает 90%
30%
снижение расходов и сокращение
периода разработки благодаря
пересмотрам, инспекции /
статическому анализу и
технологиям виртуализации
Статический анализ позволяет избежать возникновения
«периода хаоса» в начале эксплуатации и обнаруживать
дефекты на тех стадиях разработки, когда они возникают.

32. ЭКОНОМИЧЕСКАЯ ЭФФЕКТИВНОСТЬ
ПРАКТИК ПОДДЕРЖАНИЯ КАЧЕСТВА: ГРАФИК
32
Стадии
ЖЦ продукта
Стоимость
разработки Хорошая новость
жертвуя качеством,
можно быстрее
«продвинуть» продукт по
ранним стадиям
разработки
1
2
Плохая новость
по окончании стадии
реализации за
принесенное в жертву
качество придется платить
При поддержании качества
В отсутствие поддержания качества
Требования
[Requirements]
Разработка
архитектуры
[Design]
Реализация
[Implementation]
Интеграция
[Integration]
Эксплуатация
и поддержка
[Maintenance]
Тестирование
[Testing]
Требования Дизайн Реализация Тестирование

33. ПЕРЕСМОТРЫ И ЭФФЕКТИВНОСТЬ
СНИЖЕНИЯ ДЕФЕКТОЕМКОСТИ КОДА
Вид пересмотра Мин., % Медиана, % Макс., %
Пересмотр архитектуры
верхнего уровня
30 40 60
Детальный пересмотр
«функциональной архитектуры»
30 45 65
Детальный пересмотр
«логической архитектуры»
35 55 75
Статический анализ /
Инспекция кода
35 60 85
33

34. ИНСТРУМЕНТЫ СТАТИЧЕСКОГО АНАЛИЗА
34
C++
Eclipse CODAN  PVS-Studio 
Java
IntelliJ IDEA 
С#
StyleCop 
Инструменты статического анализа существуют более чем для 30 языков,
в том числе C / C++, Java, JavaScript, PHP, Python, SQL, VisualBasic,
платформы .NET и т.д.

35. ВОПРОС #3
35
КАК ОЦЕНИТЬ ИМЕЮЩЕЕСЯ И ИЗМЕРИТЬ
ПРОГРЕСС В ДВИЖЕНИИ К СВОИМ ЦЕЛЯМ?
МОДЕЛИ И АТРИБУТЫ КАЧЕСТВА

36. Неформально о качестве
Модели качества ПО
Измеряем… архитектуру
Пример: цикломатическая
сложность
Continuous Inspection: SonarQube™
36

37. НЕФОРМАЛЬНО О КАЧЕСТВЕ
37
1
2
Основная задача
… планировать и осуществлять мероприятия по
анализу и повышению структурного качества
исходного программного кода как артефакта в
процессах разработки ПО
Качество — это…
… «степень соответствия присущих характеристик <…>
изделия или продукта потребностям, ожиданиям» (ГОСТ Р
ИСО 9000). Различают качество программного
обеспечения и исходного кода.
3
Актуальность
Итеративные методы разработки; распространение
методов обеспечения и контроля качества на все этапы
разработки ПО; распространение методов ОО-анализа,
проектирования и разработки; применение UML и CASE-
средств
4
Ожидаемый результат
 Повышение качества управления рисками и
затратами на всех этапах жизненного цикла ПО

38. МОДЕЛИ КАЧЕСТВА ПО
38
Модели качества ПО — это упорядоченные системы
атрибутов, значимых для заинтересованных сторон
проекта разработки ПО
Общий принцип — числовое выражение фактора: линейная
комбинация взвешенных влияющих метрик
4,8
𝒇𝒊 = 𝒘𝒊𝒋 𝒎𝒋
𝒋
Критерии
точка зрения
разработчика
точка зрения
пользователя
Факторы
Метрики атрибуты
модели
Дж.
Маккол
Б. Боэм
ISO 9126

39. МОДЕЛЬ КАЧЕСТВА ГОСТ Р ИСО/МЭК 9126-93
И ISO 25010:2011
39
1991
2001
6
целей
ожидание
от ПО
21
атрибут
близость к
достижению
цели
ГОСТ 9126 -93
(SQuaRE)
ISO 25010:2011
5
структурных
характеристик
ПО
❶Надежность
прочность, устойчивость; степень
риска, сопряженного с
использованием системы
❷Эффективность
производительность операций;
управление ресурсами; правила
кодирования
❸Безопасность
правила кодирования; обработка
ошибок и исключений
документация в коде; удобство чтения кода;
отсутствие «грязных» техник; переносимость кода
❹Удобство сопровождения
оценка трудозатрат в ретроспективе
и перспективе
❺Размер кода

40. МЕТРИКИ КАЧЕСТВА В МОДЕЛИ ГОСТ Р
ИСО/МЭК 9126-93 И ISO 9126-2, ISO 9126-3
40
Метрики
качества
Полнота и корректность реализации
функций
Отношение числа найденных дефектов к
прогнозному
Отношение числа проведенных тестов к
общему их числу
В ТРАКТОВКЕ ISO 9126 КАЧЕСТВО ПО
МОЖНО ПОВЫСИТЬ,
НЕ ВНОСЯ В НЕГО ИЗМЕНЕНИЙ
1991
2001
6
целей
ожидание
от ПО
21
атрибут
близость к
достижению
цели
ГОСТ 9126 -93
(SQuaRE)
ISO 9126-2, ISO 9126-3

41. ИЗМЕРЯЕМ… АРХИТЕКТУРУ
41
Качественно Количественно
 Соблюдение общих принципов и
частных стандартов разработки
архитектуры
 Распределение намерений и зон
ответственности (ср. SRP) между
методами и классами
 Реализация шаблонов
проектирования разного уровня
 Степень зависимости классов друг от
друга и узость их зон ответственности
(coupling & cohesion)
 Гранулярность (granularity), главным
образом — интерфейсов
 Повторное использование (reuse)
элементов архитектуры
 Цикломатическая сложность
 Соответствие стилю ( %)
 Дублирование кода (%)

42. ПРИМЕР МЕТРИКИ:
ЦИКЛОМАТИЧЕСКАЯ СЛОЖНОСТЬ
Понятие условной, или цикломатической, сложности (Ц.с.) ПО введено в оборот
Томасом Маккейбом-ст. в статье A Complexity Measure (1976) как мера
количества линейно независимых путей в исходном коде системы, модуля,
функции, метода или класса
Исследования Т. Маккейба, К. Штайн и др. показали, что:
Ц.с. не зависит от размера программы, но зависит от наличия точек ветвления
(𝑵 точек  𝟐 𝑵
путей по управляющему графу программы)
Целесообразно ограничивать Ц.с. 𝑴 отдельных элементов ИС (модулей,
методов и т.д.) (напр. 𝑴 ⩽ 10…15)
Ц.с. является оценкой сверху количества тестовых ситуаций для достижения
полного покрытия путей в коде, а также оценкой снизу количества путей по
соответствующему графу
Большая Ц.с. обычно указывает на низкий уровень зацепления, и наоборот
42
𝐺
При наличии в функции с графом 𝐺 = 𝑉, 𝐸 , где 𝑉 —
вершины, 𝐸 — дуги, единственной точки выхода Ц.с.
функции составляет
𝑀 𝐺 = 𝐸 − 𝑉 + 𝟐

43. SONARQUBE: OPEN EJB PROJECT PROFILE
43

44. SONARQUBE:
C QUALITY PROFILE [SONAR WAY]
MINOR: 'continue' should not be used
44
int main(int argc, char* argv[]) {
int i;
for(i = 0; i < 10; i++) {
if(i == 5) {
continue; /* Non-Compliant */
}
printf("i = %dn", i);
}
return -1;
}
int main(int argc, char* argv[]) {
int i;
for(i = 0; i < 10; i++) {
if(i != 5) { /* Compliant */
printf("i = %dn", i);
}
}
return -1;
}

45. SONARQUBE:
C++ QUALITY PROFILE [SONAR WAY]
MAJOR: An unconditional throw or break statement shall terminate every non-empty
switch-clause
45
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" */
;
}

46. SONARQUBE:
JAVA QUALITY PROFILE [COMMON RULES]
MAJOR: Methods should not be too complex
46


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."
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."
MAJOR: Methods should not have too many parameters

47. СПАСИБО ЗА ВНИМАНИЕ!
❶ Собственные источники
В ходе подготовки семинара использовались:
• материалы лекций А.В. Петрова в НИУ МГТУ
им. Н.Э. Баумана по дисциплине «Системная
инженерия» (2013).
❷ Контакты
• Академия информационных систем:
www.infosystem.ru
❸ Вопросы
47

48. СПАСИБО ЗА ВНИМАНИЕ!
48

49. ЧТО ИЗУЧИТЬ [РУС]?
Вольфсон Б. Стратегия сокращения технического долга // Форум технологий 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

50. ЧТО ИЗУЧИТЬ [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 Software-
Intensive 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

51. ЧТО ИЗУЧИТЬ [ENG]? (2 / 2)
Jones, C. Software Quality in 2010: A Survey of the State of the Art. URL:
http://www.sqgne.org/presentations/2010-11/Jones-Nov-2010.pdf
Kruchten, Ph. ―Architectural Blueprints—The '4+1' View Model of Software
Architecture,‖ IEEE Software, vol. 12 (6), pp. 42–50, Nov. 1995.
McCabe, Sr., Th. J. ―A Complexity Measure,‖ IEEE Transactions on Software
Engineering, vol. 2, no. 4, pp. 308–320, Dec. 1976. URL:
http://www.literateprogramming.com/mccabe.pdf
Refactoring. URL: http://refactoring.com
Roock, S., Lippert, M. Refactoring in Large Software Projects (2006).
Shahid, H. ‖Implementing Static Code Analysis with StyleCop,‖ MSDN Magazine, Oct.
2013. URL: http://msdn.microsoft.com/en-us/magazine/dn451443.aspx
SonarQube. URL: http://www.sonarqube.org
Stein, C., et al. ―Exploring the Relationship Between Cohesion and Complexity,‖
Journal of Computer Science, vol. 1(2), pp. 137–144, 2005.
StyleCop. URL: http://stylecop.codeplex.com
51

52. ПРИЛОЖЕНИЕ: ИЗ ЧЕГО СКЛАДЫВАЕТСЯ
АРХИТЕКТУРА? [IEEE 1471-2000 С ДОП. АВТ.]
52
Миссия
Система
выполняет ▲
1..*
Внешняя
среда
влияет на ►
Архитектура
обладает ►
AD
описывается ▼
Заинтер.
сторона
обладает ▼
1..*
◄ устанавливает
1..*
Обосно-
вание
предоставляет ►
Интерес
1..*
1..*
Точка
зрения
Проекция
1..*
упорядочено
по ▼
1..*
адресуется к ▼
1..*
◄ соответствует
1..*
◄ удовлетворяет
Модель
1..*
объединяет ▼
1..*
Архитект.
элемент
состоит из ▲
Перспек-
тива