Программирование
<<  Проектирование прикладных программ Тестирование ПО  >>
Архитектура программного обеспечения
Архитектура программного обеспечения
Понятие архитектуры
Понятие архитектуры
Организационная структура
Организационная структура
Бритва Оккама
Бритва Оккама
Разделение ответственности
Разделение ответственности
Разделение абстракций
Разделение абстракций
Уровни абстракции
Уровни абстракции
Виды ответственностей
Виды ответственностей
Нефункциональные требования
Нефункциональные требования
Cross-cutting concerns
Cross-cutting concerns
Представление архитектуры
Представление архитектуры
Архитектурные шаблоны
Архитектурные шаблоны
Клиент-сервер
Клиент-сервер
Одноранговая архитектура
Одноранговая архитектура
Замечания по терминологии
Замечания по терминологии
Многоуровневая архитектура
Многоуровневая архитектура
Представление данных и персистентность
Представление данных и персистентность
Разделение бизнес-логики и интерфейса
Разделение бизнес-логики и интерфейса
Переход
Переход
Применение стереотипа subscribe
Применение стереотипа subscribe
Расщепление контроллера
Расщепление контроллера
Инкапсуляция модели
Инкапсуляция модели
Hollywood principle
Hollywood principle
Цикл обработки сообщений
Цикл обработки сообщений
Инверсия управления
Инверсия управления
Событийно-ориентированная архитектура
Событийно-ориентированная архитектура
Презентация «Архитектура программного обеспечения». Размер 159 КБ. Автор: shadow.

Загрузка...

Архитектура программного обеспечения

содержание презентации «Архитектура программного обеспечения.ppsx»
СлайдТекст
1 Архитектура программного обеспечения

Архитектура программного обеспечения

Архитектура программного обеспечения. Д. Мигинский.

2 Понятие архитектуры

Понятие архитектуры

Понятие архитектуры. – Архитектура , это совокупность решений, принимаемых системным архитектором. – Какие решения принимает архитектор? – Существенные с точки зрения архитектуры. – Какие решения существенны? – Это решает архитектор. http://www.bredemeyer.com.

3 Организационная структура

Организационная структура

Определение. Архитектура программной системы – ее организационная структура, включающая модули, их внешние характеристики, а также отношения между модулями. Обычно в архитектуру не включается внутреннее устройство отдельных модулей.

4 Бритва Оккама

Бритва Оккама

Бритва Оккама. Оригинальная формулировка: Не порождайте сущностей сверх необходимого. Применительно к программной архитектуре: Из всех архитектурных решений, которые удовлетворяют требованиям лучше то, которое проще в понимании. Формулировка для запоминания: Принцип KISS (Keep It Simple, Stupid).

5 Разделение ответственности

Разделение ответственности

Разделение ответственности. Разделение ответственностей (Separation of Concerns, SoC) – процесс разделения (программной) системы на составные части, как можно меньше дублирующие функциональность друг другу. Это основной принцип (программной) инженерии, сформулирован Э. Дейкстрой. Формулировка для запоминания: Принцип DRY (Don’t Repeat Yourself).

6 Разделение абстракций

Разделение абстракций

Разделение абстракций. Абстракция + инкапсуляция + модульность = SoC При правильном разделении ответственностей получившиеся составные части (модули) представляют собой абстракции, скрывающие внутреннее устройство и предоставляющие сравнительно простой внешний интерфейс.

7 Уровни абстракции

Уровни абстракции

Уровни абстракции. Нередко разделение абстракций представляет «слоеный пирог», тогда говорят об уровнях абстракции. Application. Presentation. Applications. Session. OS kernel. Transport. Assembler. Network. Firmware. Data link. Hardware. Physical.

8 Виды ответственностей

Виды ответственностей

Виды ответственностей (concerns). Ответственности 1-го класса: бизнес-логика приложения, следует непосредственно из функциональных требований Ответственности 2-го класса (сквозная функциональность, cross-cutting concerns): функциональность, не относящаяся к бизнес-логике, проистекающая из нефункциональных требований.

9 Нефункциональные требования

Нефункциональные требования

Нефункциональные требования. Платформа («железо», ОС, языки, библиотеки) Производительность (performance) Масштабируемость (scalability) Распределение функциональности по физическим узлам Простота поддержки, расширения, повторного использования модулей (maintainability, extensibility, reusability).

10 Cross-cutting concerns

Cross-cutting concerns

Cross-cutting concerns. Инициализация Управление жизненным циклом объектов Персистентность Журналирование Транзакции Многопоточность и синхронизация Безопасность Надежность (24/7 и т.д.) …

11 Представление архитектуры

Представление архитектуры

Представление архитектуры. Общие принципы и соглашения об организации системы: Парадигма Применение архитектурных шаблонов Архитектурные представления (4+1 модель): Logical View (классы и пакеты) Process View (процессы и синхронизация) Physical View (компоненты и узлы) Development View (организация кода) Scenario View (варианты использования).

12 Архитектурные шаблоны

Архитектурные шаблоны

Архитектурные шаблоны. Архитектурный шаблон представляет собой типичное архитектурное решение для определенного класса задач. Как правило, архитектурный шаблон определяет общий вид архитектуры системы или существенной ее части.

13 Клиент-сервер

Клиент-сервер

Клиент-сервер. Задача: обеспечить коммуникацию в распределенной среде между клиентами Решение: Клиенты взаимодействуют с единой сущностью – сервером. Между собой клиенты взаимодействовать не могут. Преимущества: Сравнительная простота реализации и конфигурации Недостатки: Сервер – потенциальное узкое место.

14 Одноранговая архитектура

Одноранговая архитектура

Одноранговая архитектура (P2P). Задача: см. «клиент-сервер» Решение: Клиенты непосредственно взаимодействуют друг с другом Преимущества: Нет явных узких мест Недостатки: Сложность реализации и конфигурации Потенциальные проблемы видимости и маршрутизации.

15 Замечания по терминологии

Замечания по терминологии

Замечания по терминологии. В общем случае: Сервер – сущность, предоставляющая функциональность Клиент – сущность, использующая функциональность Термины могут применяться безотносительно распределенных приложений.

16 Многоуровневая архитектура

Многоуровневая архитектура

Многоуровневая архитектура (N-tier Architecture). Вариант архитектуры «клиент-сервер», где функциональность делится более чем на два уровня. Каждый уровень является клиентом по отношению к нижележащему. Распространенный вариант: 3-уровневая архитектура Преимущества: распределение нагрузки между уровнями хорошая масштабируемость Замечание: для эффективного применения уровни (tiers) должны соотноситься с уровнями абстракции (layers).

17 Представление данных и персистентность

Представление данных и персистентность

3-уровневая архитектура. Data tier/layer – отвечает за представление данных и персистентность (соответствует набору entity в аналитической модели) logic tier/layer – реализует основную часть функциональности системы, отвечает также за целостность данных (~ controls) presentation tier/layer – реализует интерфейс пользователя (~ boundaries).

18 Разделение бизнес-логики и интерфейса

Разделение бизнес-логики и интерфейса

Модель-представление-управление (MVC). Задача: разделение бизнес-логики и интерфейса пользователя в соответствии с SoC Как правило, речи не идет о распределенной системе.

19 Переход

Переход

Переход от MVC к 3-tier. Шаг 1: применение стереотипа subscribe.

20 Применение стереотипа subscribe

Применение стереотипа subscribe

Переход от MVC к 3-tier. Шаг 1: применение стереотипа subscribe.

21 Расщепление контроллера

Расщепление контроллера

Переход от MVC к 3-tier. Шаг 2: расщепление контроллера.

22 Инкапсуляция модели

Инкапсуляция модели

Переход от MVC к 3-tier. Шаг 3: инкапсуляция модели.

23 Hollywood principle

Hollywood principle

Hollywood Principle. Don’t call us, we’ll call you.

24 Цикл обработки сообщений

Цикл обработки сообщений

Цикл обработки сообщений WinAPI. int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 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). Задача: использовать альтернативный механизм запуска и/или исполнения приложения (вычислительную модель) Решение: фреймворк реализует “main” с соответствующей вычислительной моделью, пользовательский код явной точки входа не содержит Основные области применения: Управление жизненным циклом объектов и связей (Dependency Injection) Интерфейсы пользователя Альтернативные вычислительные модели (автоматы, продукции, потоки данных и т.д.).

26 Событийно-ориентированная архитектура

Событийно-ориентированная архитектура

Событийно-ориентированная архитектура. Задача: Обеспечить взаимодействие между модулями без жесткой их привязки друг к другу Решение: Модули взаимодействуют в терминах посылки сообщений и реакции на них. Как правило, сообщения асинхронны. Недостатки: шина сообщений может быть узким местом Применение: Интерфейс пользователя Взаимодействие приложений Распределенные вычисления (MPI).

«Архитектура программного обеспечения»
Загрузка...
Сайт

5informatika.net

115 тем
5informatika.net > Программирование > Архитектура программного обеспечения.ppsx