1. Производительность.
Антипатерны
 Имя
Класс ―бог (―god class)
 Симптомы
 Единственный сложный контроллер
 Использует простые классы – контейнеры данных
 В свою очередь, классы контейнеры
• Содержат только методы доступа и модификаторы (get, set)
• Не поддерживают поведения (или поддерживают слабо)
 Проблема
 Класс «Бог» становится причиной интенсивного трафика сообщений
• В форме контроллера запрашивает и обновляет данные у подконтрольных классов
• В форме контейнера данных – запрашивает и обновляет данные в божественном классе
• Количество вызовов для выполнения операции много больше чем при хорошем дизайне
 Решение
 С помощью рефакторинга распределите поведение по всем top-level классам приложения
 Переместите поведение ближе к данным
 Избегайте ситуаций, когда
• Объект запрашивает данные у других объектов и затем обновляет их самостоятельно
• Группа объектов запрашивает и обновляет данные одного общего объекта
 Используйте Принцип Локальности
• Алгоритм и данные необходимые для его выполнения должны располагаться вместе
38 МАИ, каф 806, ППС

2. Производительность.
Антипатерны
 Имя
Чрезмерное динамическое выделение ресурсов (excessive dynamic allocation)
 Симптомы
 Динамическим выделением объекта называется ситуация, когда объект
• Создается при первом вызове
• Уничтожается при отсутствии потребности
 Проблема
 При создании объекта
• должна быть выделена память для его размещения (и для объектов, которые он содержит)
• должен быть выполнен код инициализации объекта (и объектов, которые он содержит)
 Когда объект больше не нужен
• выполняются операции завершения
• выполняются операции дефрагментации памяти
 Влияние на производительность может быть значительным при больших количество объектов, которые часто создаются и
затем уничтожаются
 Решение
 Используйте пул (―pool) объектов, коллекцию объектов, который
• Позволяет повторно использовать объекты вместо того, чтобы создавать их вновь при каждой необходимости
• Бывает очень полезен при наличии в системе множества короткоживущих объектов
 Используйте разделенные (sharing) объекты вместо того, чтобы создавать новые
39 МАИ, каф 806, ППС

3. Производительность.
Антипатерны
 Имя
Поэтапный поиск сокровищ (circuitous treasure hunt)
 Симптомы
 Система запрашивает данные в одной таблице, затем на основании этих данных осуществляет запрос к
другой таблице и далее в том же духе до получения финального результата
 Проблема
 В объектно-ориентированных системах операции включают множество запросов
• Объект вызывает операции другого, тот в свою очередь третьего, и так далее до получения
финального результата
• Каждая операция возвращает значения по цепочке объекту, который был инициатором вызовов
• Возникает существенное снижение производительности. Особенно в распределенных системах
 Решение
 Измените структуру организации данных
 Разместите вместе совместно используемые данные
 Для решения проблемы множества вызовов создавайте новые связи-ассоциации, которые ведут
непосредственно к финальному результату
40 МАИ, каф 806, ППС

4. Производительность.
Антипатерны
 Имя
Мост с односторонним движением (the one lane bridge)
 Симптомы
 это решение, при котором
• передача возможно только в одну сторону в каждый конкретный момент времени
• если передача ведется параллельно по нескольким полосам, все потоки должны сойтись в одной точке
 Проблема
 Только один или небольшое количество процессов могут работать одновременно
• все остальные процессы находятся в состоянии ожидания
 Пример:
• Блокировка база данных позволяет только одному процессу обновлять определенные данные в конкретный момент
времени
• Много процессов осуществляют синхронный вызов другого не многопоточного процесса
• Первичный ключ в базе данных строится на основании последовательности
 Решение
 Обеспечивайте дополнительные маршруты в обход однопоточного моста
 Решение базируется на Принципе распределения ресурсов
• Реактивность увеличивается при снижении времени обслуживания и времени ожидания
• Время ожидания в свою очередь уменьшается за счет времени обслуживания и нахождения обходных маршрутов
41 МАИ, каф 806, ППС

5. Производительность.
Антипатерны
 Имя
Пробка (traffic jam)
 Симптомы
 Большая очередь работ ожидающих обслуживания
• Мост с односторонним движением приводит к большим задержкам, после которых требуется
много времени для восстановления нормального режима работы
• Большое количество работы запланировано на сравнительно небольшой интервал времени
• Все пользователь нуждаются в отчетах в одно и то же время
• На рынке происходит всплеск активностей
 Проблема
Проблема в больших вариации времени отклика
 Решение
 Если проблема вызвана Мостом с односторонним движением, решите проблему с Мостом
 Если проблема связанна с периодически возрастающими запросами, решайте проблему
распределением нагрузки или регулируйте поток запросов
42 МАИ, каф 806, ППС

6. Производительность.
Антипатерны
 Имя
Несбалансированная обработка (unbalanced processing)
 Симптомы
 Параллельная обработка должна приводить к улучшению маштабируемости, однако этого не происходит, если все
параллельные потоки вынуждены ожидать завершение другого процесса
 Проблема
 Системы Параллельной обработки при наличии множества процессоров не можем использовать параллельную обработку, к
примеру, потому что используется single-threaded код
 Архитектура ―Pipe and Filter Пропускная способность определена самым медленным фильтром
 Интенсивная обработка Параллельные вычисления не могут быть использованы эффективно, потому что процессор
загружен интенсивными вычислениями
 Решение
 Конкурентная обработка
• Если мы имеем дело с single-threading процессом, то мы можем либо переписать его с использованием multi-threaded
или использовать множество копий
• Если процессор занят интенсивными вычислениями, требуется тьюнинг системы. В частности перераспределение
нагрузки между процессорами
 Архитектура ―Pipe and Filter
• Моделируйте ситуацию для выявления узких мест
• При необходимости разбивайте большие процессы на множество мелких (который возможно распараллелить)
• При необходимости объединяйте процессы в один большой (экономия за счет использования общего контекста)
43 МАИ, каф 806, ППС

7. Производительность.
Антипатерны
 Имя
Ненужная обработка (unnecessary processing)
 Симптомы
 Как и любая другая бесполезная работа работа по этому шаблону отнимает время у важной задачи
 Проблема
 Ненужная обработка может быть вообще бессмысленной или ненужной в это время
 Например, система логирует исходящие и входящие сообщения. Одна группа логов лишняя, так как
может быть восстановлена по второй
 Решение
 Зачастую решение проблемы сводится к устранению ненужного кода
 Возможна реорганизация шагов обработки, позволяющая исключить из обработки неактуальные
устаревшие данные
 Третье решение - перенос ненужных обработок в фоновый процесс
44 МАИ, каф 806, ППС

8. Производительность.
Антипатерны
 Имя
Наклонная (the ramp)
 Симптомы
 Системы показывают замечательную производительность при старте, но с каждой минутой их
производительность падает
 Проблема
 Причин возникновения такой ситуации может быть множество
• В частности, в процессе работы накапливаются данные, участвующие в принятии дальнейших
решений
• В процессе поиска выбираем значения группами (например по 10), каждый новый поиск дает все
те же результаты и отсеивает ненужные
 Решение
 Выбирайте алгоритмы поиска, пригодные как для больших так и для малых объемов данных,
исключающие дополнительную работу по поиску в найденном
 Возможно, стоит использовать самонастраивающуюся (по размеру) стратегию поиска
 Если данные увеличиваются постепенно, необходимо иметь систему мониторинга, переключающую
стратегию работы при достижении определенной контрольной точки
45 МАИ, каф 806, ППС

9. Производительность.
Антипатерны
 Имя
Дальше хуже (more is less)
 Симптомы
 Чем больше мы производим работы, тем дальше от конечного результата
 Проблема
 Наиболее частая причина – нехватка памяти. Множество задач интенсивно используют память, мешая
друг другу
 Слишком много соединений с базой данных
 Слишком много сетевых соединений
 Слишком много ресурсов взято из пулла
 Решение
 Переход от многопотоковой системы к однопотоковому варианту
 Поток поддерживает очередь Команд [Gof] с предустановленными приоритетами
 Пересмотреть балансы системы или подсистем
 Например, снизить требование по количеству одновременных соединений с базой данных с 200 до 100
46 МАИ, каф 806, ППС

10. Производительность.
Антипатерны
 Имя
Эффект домино (falling dominoes)
 Симптомы
 Одна проблема тянет за собою другую, та – следующую и так далее
 Проблема
 Падение одного узла приводит к увеличению нагрузки на другие, что приводит к их
падению
 Увеличение времени отклика приводи к череде повторных запросов
 Решение
 Изолируйте сбойный элемент
• Если нет доступа к базе данных, отключите сервис, исключив ―DOSǁ атаку
повторных обращений
47 МАИ, каф 806, ППС

11. Производительность.
Антипатерны
 Имя
Порожняк (empty semi trucks)
 Симптомы
 Сервис работает над выполнением простейших запросов
 Проблема
 Для выполнения задачи требуется огромное количество запросов. Каждый из запросов
довольно мизерный
 Проблема возникает
• из-за неэффективного использования коммуникаций
• из-за плохо спроектированного интерфейса
 Решение
 Если проблема в неэффективном использовании логического канала связи, используйте
пакетирование
 Если проблема в плохо спроектированном интерфейсе, перепроектируйте его, с целью
расположения данных ближе к алгоритму обработки
48 МАИ, каф 806, ППС

12. Производительность.
Антипатерны
 Имя
Вавилонская башня (tower of Babel)
 Симптомы
 Процессы в параллельной обработке имеют различный формат представления
информации
 Проблема
 Часть системы работает с одним форматом передачи данных, часть с другим.
Накладные расходы возникают при переводе из одного формата в другой
 Решение
 Если проблема возникает на быстром пути обработки (Fast Path), можно
перепроектировать модули с целью расположения данных ближе к алгоритму обработки
49 МАИ, каф 806, ППС

13. Атрибуты качество ПО. Модифицируемость.
50 МАИ, каф 806, ППС

14. Локализация модификаций
 Поддержка семантической связанности.
Ответственности модулей разбиваются на стадии проектирования, т.к. что бы каждая
ответственность попадала внутрь определенного модуля и не делилась. Выделение общих
функций в отдельные модули (Framework).
 Предвосхищение ожидаемых изменений.
На стадии проектирования задаются вопросы, какие изменения в системе возможны? Цель -
что бы однотипные изменения приводили к доработкам одних и тех же модулей.
 Обобщение модуля.
Использование модифицируемых интерфейсов (расширяемые протоколы, интерпретируемый
формат данных). Модуль разделяется на интерпретатор внешних запросов и сам модуль.
Позволяет модифицировать модуль меняя интерпретатор внешних запросов а не сам модуль.
 Ограничение модифицируемости.
Для каждого модуля на стадии проектирования определяются возможности модификации.
Что дает возможность уменьшить влияние модификаций (но и ухудшить модифицируемость
продукта).
51 МАИ, каф 806, ППС

15. Предотвращение модификации модулей, напрямую не
связанных с модификацией самого модуля. [1/5]
Синтаксические - сигнатуры данных производимых модулем А,
должны соответствовать ожиданием модуля Б, сигнатуры
вызываемых методов - аналогично.
Пример:
 Модуль A вызывает метод “int doHelloWorld(string name)”
 Модуль B реализует метод “int doHelloWorld(string name)”
52 МАИ, каф 806, ППС

16. Предотвращение модификации модулей, напрямую не
связанных с модификацией самого модуля. [2/5]
Семантические - смысл данных производимых модулем А,
совпадает со смыслом ожидаемым модулем Б, аналогично с
методами.
Пример:
 Модуль A вызывает метод “int doHelloWorld(string name)”.
Где имя передается в формате «Имя Отчество Фамилия»
 Модуль B реализует метод “int doHelloWorld(string name)”
Где имя ожидается в формате «Имя Отчество Фамилия»
53 МАИ, каф 806, ППС

17. Предотвращение модификации модулей, напрямую не
связанных с модификацией самого модуля. [3/5]
 Последовательность - если определена последовательность в которой передаются
данные, то она должна пониматься одинакова обеими сторонами. Так же если второй
вызов может идти вслед за первым в установленный промежуток времени.
Пример
1. Передается запрос на открытие сессии.
2. Передаются данные
3. Получаются данные
4. Передается запрос на закрытие сессии.
54 МАИ, каф 806, ППС

18. Предотвращение модификации модулей, напрямую не
связанных с модификацией самого модуля. [4/5]
 Идентификация интерфейса. Модуль Б должен знать корректную
идентификацию (имя) интерфейса А.
Пример
Если модуль B реализует интерфейс IHelloWorld. То модуль А должен знать
что это интерфейс IHelloWorld.
 Расположение модуля Что бы Б запускался правильно он должен знать
откуда будет вызываться модуль А.
Пример
При вызове .NET Remoting необходимо знать URL хоста сервиса.
55 МАИ, каф 806, ППС

19. Предотвращение модификации модулей, напрямую не
связанных с модификацией самого модуля. [5/5]
 Качество данных. Могут быть предположения о структуре данных (определенная
точность).
Пример
В бухгалтерской программе может быть заранее оговорено, что деньги имеют точность 4
знака после запятой, что бы исключить расхождения из-за неверного округления.
 Существование модуля. Если модуль не существует то другой не сможет его
использовать.
Пример
В коде модуля А может быть явно прописана процедура создания экземпляра модуля B
(скажем вызов конструктора). Если бы нужный интерфейс реализовывался бы другим
модулем, то пришлось бы вызывать другой конструктор.
 Управление ресурсами. Модуль должен работать с ресурсами на основании
предположений вызывающего модуля. Например, использовать с ним общую память.
56 МАИ, каф 806, ППС

20. Тактики.
Уменьшение связанности
 Скрытие внутреннего поведения модуля. Скрытие внутренних функций в модуле с
обеспечением доступа через public интерфейсы.
 Уменьшение путей коммуникации. Уменьшение числа модулей которые разделяют
информацию с текущим модулем. Это уменьшает связи между модулями. И позволяет
уменьшить эффект каскадных изменений.
 Поддержка ранее созданных интерфейсов. В случае если мы зафиксировали интерфейс,
то меняя реализацию вызываемого модуля мы оставляем вызывающий модуль неизменным
(в случае если не меняется семантика данных, качество и т.д.)
57 МАИ, каф 806, ППС

21. Тактики.
Уменьшение связанности
 Применение посредников . Применение модулей-посредников позволяет оградить один
модуль от модификаций другого (в случае, если не меняется семантика данных). Типы
посредников:
 Изменение данных. Создаются словари для преобразования данных из одного
формата в другой формат.
 Изменение сервисов. Façade, bridge, mediator, strategy,proxy and factory позволяют
создать и работать с промежуточным слоем.
 Изменение названия интерфейса. Паттерн Broker позволяет не менять вызывающий
модуль, если на сервере поменялось название интерфейса путем настроек брокера.
 Изменение места расположения сервисов. Использование Name-серверов,
отвечающих за определение места положения сервиса по имени.
 Изменение метода управления ресурсами. Применение централизованного модуля
управления ресурсами позволяет всем модулям работать с ресурсами одинаково
(например, может быть единый модуль создающий потоки выполнения и гарантирующий
что количество потоков не будет превышено).
 Существование модуля. Factory может создавать как сам модуль так и заглушку.
58 МАИ, каф 806, ППС

22. Тактики.
Отложенное связывание
 Runtime registration использование механизмов plugin.
 Configuration files конфигурирование системы при старте.
 Polymorphism использование наследования для переопределения классов.
 Component replacement подмена компонент (библиотек) при загрузки системы.
 Строгое соблюдение протокола позволяет связывать в runtime независимые
процессы.
59 МАИ, каф 806, ППС

23. Атрибуты качество ПО. Модифицируемость
Пример: DDD
 Подход, позволяющий быстро
проектировать стабильную архитектуру
приложения, основываясь на терминах
предметной области.
 Основные способы определения модулей:
 Layers
 Entity
 Value Object
 Services
 Repository
60 МАИ, каф 806, ППС

24. Атрибуты качество ПО. Модифицируемость
Пример: DDD. Layers
 Разделение программного обеспечения на
слои согласно выполняемым функциям с
точки зрения программного обеспечения.
 Например:
 Слой пользовательского интерфейса;
 Слой бизнес-логики;
 Слой информации о домене сущностей;
 Слой доступа к данным;
 Должно быть четкое разделение слоев.
 Должны быть определены правила
взаимодействия слоев (интерфейсы).
61 МАИ, каф 806, ППС

25. Атрибуты качество ПО. Модифицируемость
Пример: DDD. Entity
 Представляют объекты реального мира;
 Обладают идентификацией (например, номер
паспорта + дата и место выдачи для
человека)
 Обладают явно выраженным жизненным
циклом (процедурой создания, удаления,
изменения состояния)
 Обладают поведением.
62 МАИ, каф 806, ППС

26. Атрибуты качество ПО. Модифицируемость
Пример: DDD. Value Object
 Не обладают идентификацией
Могут копироваться и передаваться от
функции к функции без ограничений.
 Не обладают жизненным циклом
Создаются когда надо и удаляются, когда
ни кем не используются
 Зачастую не меняют своих атрибутов
Могут быть доступны для коллективного
доступа из разных частей программы.
 Атрибуты составляющие Value Object
должны быть концептуально полными
(соответствовать какой-либо абстракции)
63 МАИ, каф 806, ППС

27. Атрибуты качество ПО. Модифицируемость
Пример: DDD. Services
 Основные свойства:
 Описывают процессы, работающие с Entity и Value Object в терминах предметной
области
 Не имеют состояния;
 Не заменяют операции, которые принадлежат Entity, а дополняет их. Обычно сервис
является важным процессом с точки зрения домена;
 Разделяют сервисы, принадлежащие уровню домена и сервисы, принадлежащие
инфраструктуре (например, доступ к данным)
 Command Query Separation
“every method should either be a command that performs an action, or a query that returns data to
the caller, but not both. In other words, asking a question should not change the answer”
Bertrand Meyer
64 МАИ, каф 806, ППС

28. И ещё раз о разделении системы на объекты: API
http://chaos.troll.no/~shausman/api-design/api-design.pdf
 API должно быть
 Быть минимальным. Минимальное API содержит как можно меньше открытых членов
на класс и как можно меньше классов. Благодаря этому можно легко понять, запомнить,
тестировать и изменять API.
 Быть полным. Полное API подразумевает покрытие всей функциональности. Правда,
это мешает сохранению минимальности. А еще, если член класса, находится в
неправильном классе, то это приведет к тому, что пользователи не смогут найти эту
функцию. (tools/assistant/compat/compat.pro)
 Обладать прозрачной и просто семантикой. Необходимо следовать принципу
наименьшего удивления: сделать общие задачи проще. Должна быть возможность
выполнять редкие задачи, но не стоит заострять внимание на них. Надо решать
конкретные проблемы, а не делать общие решения, когда в этом нет необходимости.
65 МАИ, каф 806, ППС

29. И ещё раз о разделении системы на объекты: API
 Интуитивно понятный. API, как и все остальное в компьютере, должно быть интуитивно
понятным. Разные условия и опыт приводят к разным взглядам на то, что является
интуитивным, а что — нет. Интуитивно понятное API, это такое API, которым может
пользоваться среднестатистический пользователь, не читая документацию и программист,
который не знает API, может понять код, в котором он используется.
 Легко запоминающийся. Что бы сделать API легко запоминающимся, необходимо
использовать прямые и точные названия. Использовать наглядные шаблоны и концепции,
избегая сокращений.
 Способствовать написанию читаемого кода. Код пишется один раз, но затем читается (и
тестируется, и изменяется) множество раз. Написание читаемого кода может потребовать
больше времени, чем обычно, но сэкономит время на протяжении всего жизненного цикла
продукта.
 Ну и наконец, имейте ввиду, что разные пользователи будут пользоваться разными частями
API.
66 МАИ, каф 806, ППС

30. Атрибуты качество ПО. Модифицируемость
Пример: DDD. Modules, repository
 Modules
Состоят из элементов, логически связанных друг с другом.
 Агрегаты
Группа связанных объектов, которые могут рассматриваться как одно целое
 Фабрики
Инкапсулирую процесс создания сложных объектов или группы объектов
 Репозитории
Реализуют логику получения ссылки на объекты предметной области по разным
критериям
67 МАИ, каф 806, ППС

31. DDD
итого
68 МАИ, каф 806, ППС

32. Уровни зрелости модульной структуры ПО
 Level 1: Ad Hoc
Ни какой специальной модульной структуры нет.
Плюсы: просто и дешево.
 Level 2: Modules
Модули отделены от друг друга, имеют версию и свой идентификатор.
Плюсы: отделение модулей от кода, упрощение работы с зависимостями в коде и версионной сборки.
 Level 3: Modularity
Модуль может манятся автономно, не зависимо от других модулей. Модуль описывается своим
«контрактом».
Плюсы: Возможность предсказать сложность внесения изменений в систему.
 Level 4: Loose coupling
Разделение интерфейса и реализации.
Плюсы: Независимость поставщика и получателя интерфейса.
 Level 5: Devolution (ограниченная автономия)
Артефакты модулей храниться в репозиториях. Модули собираются из артефактов в зависимости от
необходимых сервисов.
Плюсы: уменьшение дублирования, улучшенная независимость модулей.
 Level 6: Dynamism
Динамическое управление жизненным циклом модуля. Поддержка операций добавления./ изменения
модуля.
Плюсы: Динамическое развитие системы и управление.
69 МАИ, каф 806, ППС

33. Модифицируемость vs Performance
 Разделение данных на домены ведет к увеличению
распределенности объектов между сервисами, что
ухудшает производительность.
 Разделение системы на слои, увеличивает количество
преобразований данных, что так же отрицательно
влияет на производительность.
 Использование операций в терминах домена приводит
к тому, что появляется дополнительное
преобразование данных из внутренней модели во
внешнюю. Что так же отрицательно влияет на
производительность.
70 МАИ, каф 806, ППС