Слайд 2Понятие архитектуры
– Архитектура , это совокупность решений,
принимаемых системным архитектором.
– Какие решения
![Понятие архитектуры – Архитектура , это совокупность решений, принимаемых системным архитектором. –](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-1.jpg)
принимает архитектор?
– Существенные с точки зрения архитектуры.
– Какие решения существенны?
– Это решает архитектор.
http://www.bredemeyer.com
Слайд 3Определение
Архитектура программной системы –
ее организационная структура, включающая
модули, их внешние характеристики, а
![Определение Архитектура программной системы – ее организационная структура, включающая модули, их внешние](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-2.jpg)
также отношения между модулями.
Обычно в архитектуру не включается внутреннее устройство отдельных модулей.
Слайд 4Бритва Оккама
Оригинальная формулировка:
Не порождайте сущностей сверх необходимого.
Применительно к программной архитектуре:
Из всех архитектурных
![Бритва Оккама Оригинальная формулировка: Не порождайте сущностей сверх необходимого. Применительно к программной](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-3.jpg)
решений, которые удовлетворяют требованиям лучше то, которое проще в понимании.
Слайд 5Разделение ответственности
Разделение ответственностей (Separation of Concerns, SoC) – процесс разделения (программной) системы
![Разделение ответственности Разделение ответственностей (Separation of Concerns, SoC) – процесс разделения (программной)](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-4.jpg)
на составные части, как можно меньше дублирующие функциональность друг другу.
Это основной принцип (программной) инженерии, сформулирован Эдсгером Дейкстрой.
Слайд 6Разделение абстракций
SoC + ООП (абстракция и инкапсуляция):
При правильном разделении ответственностей получившиеся составные
![Разделение абстракций SoC + ООП (абстракция и инкапсуляция): При правильном разделении ответственностей](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-5.jpg)
части (модули) представляют собой абстракции, скрывающие внутреннее устройство и предоставляющие сравнительно простой внешний интерфейс
Слайд 7Уровни абстракции
В частных случаях разделение абстракций представляет «слоеный пирог», тогда говорят об
![Уровни абстракции В частных случаях разделение абстракций представляет «слоеный пирог», тогда говорят об уровнях абстракции.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-6.jpg)
уровнях абстракции.
Слайд 8Виды ответственностей (concerns)
Ответственности 1-го класса: бизнес-логика приложения, следует непосредственно из функциональных требований
Ответственности,
![Виды ответственностей (concerns) Ответственности 1-го класса: бизнес-логика приложения, следует непосредственно из функциональных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-7.jpg)
соответствующие нефункциональным требованиям
Ответственности 2-го класса (сквозная функциональность, cross-cutting concerns): функциональность, не относящаяся к бизнес-логике
Слайд 9Нефункциональные требования
Платформа («железо», ОС, языки, библиотеки)
Производительность (performance)
Масштабируемость (scalability)
Распределение функциональности по физическим узлам
Простота
![Нефункциональные требования Платформа («железо», ОС, языки, библиотеки) Производительность (performance) Масштабируемость (scalability) Распределение](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-8.jpg)
поддержки, расширения, повторного использования модулей (maintainability, extensibility, reusability)
Слайд 10Cross-cutting concerns
Инициализация
Управление жизненным циклом объектов
Персистентность
Журналирование
Транзакции
Многопоточность и синхронизация
Безопасность
…
![Cross-cutting concerns Инициализация Управление жизненным циклом объектов Персистентность Журналирование Транзакции Многопоточность и синхронизация Безопасность …](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-9.jpg)
Слайд 11Представление архитектуры
Общие принципы и соглашения об организации системы:
Парадигма
Применение архитектурных шаблонов
Архитектурные представления (4+1
![Представление архитектуры Общие принципы и соглашения об организации системы: Парадигма Применение архитектурных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-10.jpg)
модель):
Logical View (классы и пакеты)
Process View (процессы и синхронизация)
Physical View (компоненты и узлы)
Development View (организация кода)
Scenario View (варианты использования)
Слайд 12Архитектурные шаблоны
Архитектурный шаблон представляет собой типичное архитектурное решение для определенного класса задач.
![Архитектурные шаблоны Архитектурный шаблон представляет собой типичное архитектурное решение для определенного класса](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-11.jpg)
Как правило, архитектурный шаблон определяет общий вид архитектуры системы или существенной ее части.
Слайд 13Клиент-сервер
Задача: обеспечить коммуникацию в распределенной среде между клиентами
Решение:
Клиенты взаимодействуют с единой
сущностью
![Клиент-сервер Задача: обеспечить коммуникацию в распределенной среде между клиентами Решение: Клиенты взаимодействуют](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-12.jpg)
– сервером. Между собой
клиенты взаимодействовать не могут.
Преимущества:
Сравнительная простота реализации
и конфигурации
Недостатки:
Сервер – потенциальное
узкое место
Слайд 14Одноранговая архитектура (P2P)
Задача: см. «клиент-сервер»
Решение:
Клиенты непосредственно
взаимодействуют друг с другом
Преимущества:
Нет явных узких мест
Недостатки:
Сложность
![Одноранговая архитектура (P2P) Задача: см. «клиент-сервер» Решение: Клиенты непосредственно взаимодействуют друг с](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-13.jpg)
реализации и конфигурации
Потенциальные проблемы видимости и маршрутизации
Слайд 15Замечания по терминологии
В общем случае:
Сервер – сущность, предоставляющая
функциональность
Клиент – сущность, использующая
![Замечания по терминологии В общем случае: Сервер – сущность, предоставляющая функциональность Клиент](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-14.jpg)
функциональность
Термины могут применяться безотносительно распределенных приложений
Слайд 16Многоуровневая архитектура (N-tier Architecture)
Вариант архитектуры «клиент-сервер»,
где функциональность делится более чем
на два уровня.
![Многоуровневая архитектура (N-tier Architecture) Вариант архитектуры «клиент-сервер», где функциональность делится более чем](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-15.jpg)
Каждый уровень является клиентом
по отношению к нижележащему.
Распространенный вариант: 3-уровневая
архитектура
Преимущества:
распределение нагрузки между уровнями
хорошая масштабируемость
Замечание: для эффективного применения
уровни (tiers) должны соотноситься с уровнями
абстракции (layers)
Слайд 173-уровневая архитектура
Data Tier/Layer – отвечает за представление данных и персистентность (соответствует набору
![3-уровневая архитектура Data Tier/Layer – отвечает за представление данных и персистентность (соответствует](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-16.jpg)
entity в аналитической модели)
Logic Tier/Layer – реализует основную часть функциональности системы, отвечает также за целостность данных (~ controls)
Presentation Tier/Layer – реализует интерфейс пользователя (~ boundaries)
Слайд 18Модель-представление-управление (MVC)
Задача: разделение бизнес-логики и интерфейса пользователя в соответствии с SoC
Как
![Модель-представление-управление (MVC) Задача: разделение бизнес-логики и интерфейса пользователя в соответствии с SoC](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-17.jpg)
правило, речи не идет о распределенной системе
Слайд 19Переход от MVC к 3-tier
Шаг 1: применение стереотипа subscribe
![Переход от MVC к 3-tier Шаг 1: применение стереотипа subscribe](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-18.jpg)
Слайд 20Переход от MVC к 3-tier
Шаг 1: применение стереотипа subscribe
![Переход от MVC к 3-tier Шаг 1: применение стереотипа subscribe](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-19.jpg)
Слайд 21Переход от MVC к 3-tier
Шаг 2: расщепление контроллера
![Переход от MVC к 3-tier Шаг 2: расщепление контроллера](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-20.jpg)
Слайд 22Переход от MVC к 3-tier
Шаг 3: инкапсуляция модели
![Переход от MVC к 3-tier Шаг 3: инкапсуляция модели](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-21.jpg)
Слайд 23Hollywood Principle
Don’t call us, we’ll call you
![Hollywood Principle Don’t call us, we’ll call you](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-22.jpg)
Слайд 24Цикл обработки сообщений WinAPI
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR
![Цикл обработки сообщений WinAPI int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-23.jpg)
lpCmdLine,
int nCmdShow)
{
MSG msg;
while(GetMessage(&msg, NULL, 0, 0) > 0) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
Слайд 25Инверсия управления (Inversion of Control, IoC, Hollywood Principle)
Задача: использовать альтернативный механизм запуска
![Инверсия управления (Inversion of Control, IoC, Hollywood Principle) Задача: использовать альтернативный механизм](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/368812/slide-24.jpg)
и/или исполнения приложения (вычислительную модель)
Решение: фреймворк реализует “main” с соответствующей вычислительной моделью, пользовательский код явной точки входа не содержит
Основные области применения:
Управление жизненным циклом объектов и связей (Dependency Injection)
Интерфейсы пользователя
Альтернативные вычислительные модели (автоматы, продукции, потоки данных и т.д.)