Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Разработка архитектуры ПС
Содержание
- 1. Разработка архитектуры ПС
- 2. 08/13/2019СодержаниеПонятие архитектурыОсновные разновидности архитектурАрхитектурные функцииКонтроль архитектуры
- 3. 08/13/2019Что такое архитектура?Общий взгляд на ПС извне
- 4. 08/13/2019Учет требований при создании архитектурыОсновные цели разработки:Расширение
- 5. 08/13/2019СтруктуризацияВыполняется в виде блочной диаграммы, отражающей иерархию
- 6. 08/13/2019Повторное использование архитектурыМногие системы строятся на общих
- 7. 08/13/2019Архитектурные моделиПредставляют описание архитектуры с различных сторонСтатические
- 8. 08/13/2019Основные классы архитектурных моделей
- 9. 08/13/2019Системная организацияОтражает базовую стратегию структуризации системыЧетыре основных
- 10. 08/13/2019Системы потоков данныхПроцесс обработки управляется даннымиДанные перемещаются между этапами обработкиОсновные элементы: поток данных, процесс, файл
- 11. 08/13/2019Варианты систем потоков данныхТрансформер – входящий поток
- 12. 08/13/2019РепозиторийДанные содержатся в общей базе (репозитории)Компоненты обмениваются данными неявноНеобходимы средства синхронизацииУдобно для обмена большими объемами данных
- 13. 08/13/2019Виды репозиториевПассивный – входящий поток событий или
- 14. 08/13/2019Пример: CASE-система
- 15. 08/13/2019Клиент-серверМодель распределенной системы, отражающая распределение данных и
- 16. 08/13/2019Характеристики модели «клиент-сервер»ПреимуществаПростое и очевидное распределение данныхОриентированность
- 17. 08/13/2019Виды модели «клиент-сервер»«Толстый» клиент«Толстый» серверСбалансированная системаPeer2PeerРаспределенный клиент или сервер
- 18. 08/13/2019Разновидности серверовСервер без состояния – не хранит
- 19. 08/13/2019Модель абстрактной машиныОписывает интерфейс между подсистемамиПредставляет систему
- 20. 08/13/2019Характеристики абстрактной машиныПреимущества:Повышение уровня абстракции – возможность
- 21. 08/13/2019Модели управленияОпределяют потоки управления между подсистемамиОсновные модели:Централизованное
- 22. 08/13/2019Централизованное управлениеМодель «вызов-возврат»Процедурная модель, когда вызов проходит
- 23. 08/13/2019Управление на базе событийДействия системы зависят от поступающих извне событийДве основных модели:Широковещательная модельСистемы с прерываниями
- 24. 08/13/2019Широковещательная модельСобытие передается всем подсистемамПодсистема реагирует на
- 25. 08/13/2019Характеристики широковещательной моделиПреимуществаПростота расширения – подсистема регистрируется
- 26. 08/13/2019Система с прерываниямиГарантирует быстрый ответ на внешние
- 27. 08/13/2019Слоистая архитектураСостоит из уровней – логически связанных
- 28. 08/13/2019Архитектурные функцииОбеспечивают взаимодействие между подсистемамиРасширяют спецификацию ПСРеализуют механизмы взаимодействия (порты, сообщения и др.)
- 29. 08/13/2019Система портовПорт – подсистема для обслуживания очереди сообщенийИмеет общесистемное обозначениеВо многих случаях реализуется на уровне ОС
- 30. 08/13/2019Гибкие и жесткие портыЖесткий порт – явно
- 31. 08/13/2019Системы с сообщениямиОбеспечивают эффективное удаленное взаимодействиеТребуют наличия
- 32. Скачать презентанцию
08/13/2019СодержаниеПонятие архитектурыОсновные разновидности архитектурАрхитектурные функцииКонтроль архитектуры
Слайды и текст этой презентации
Слайд 208/13/2019
Содержание
Понятие архитектуры
Основные разновидности архитектур
Архитектурные функции
Контроль архитектуры
Слайд 308/13/2019
Что такое архитектура?
Общий взгляд на ПС извне и его представление
в виде системы из взаимодействующих компонентов
Цель проектирования – выбор архитектуры,
соответствующей требованиям к ПСЗадача проектирования – создание описания ПС в виде набора подсистем
Слайд 408/13/2019
Учет требований при создании архитектуры
Основные цели разработки:
Расширение – поддержка добавления
новых возможностей в приложение
Изменение – облегчение смены требований в процессе
эксплуатации приложенияПростота – упрощение с целью возможности быстрой реализации
Эффективность – достижение эксплуатационных характеристик
Слайд 508/13/2019
Структуризация
Выполняется в виде блочной диаграммы, отражающей иерархию компонентов
Каждый блок соответствует
компоненту, блоки внутри блоков – вложенным подсистемам
Стрелки указывают поток данных
или управления между подсистемами
Слайд 608/13/2019
Повторное использование архитектуры
Многие системы строятся на общих принципах, свойственных приложениям
определенной предметной области
Многие ПС имеют различные версии, основанные на одной
и той же архитектуреИспользуются шаблоны архитектур – справочный код (reference code)
Слайд 708/13/2019
Архитектурные модели
Представляют описание архитектуры с различных сторон
Статические модели
Динамические модели процессов
Модели
интерфейсов между компонентами
Модели отношений (например, DFD)
Модели развертывания
Слайд 908/13/2019
Системная организация
Отражает базовую стратегию структуризации системы
Четыре основных типа организации:
Системы потоков
данных
Репозиторий разделяемых данных
Разделяемые сервисы и серверы
Абстрактная машина (слоистая архитектура)
Слайд 1008/13/2019
Системы потоков данных
Процесс обработки управляется данными
Данные перемещаются между этапами обработки
Основные
элементы: поток данных, процесс, файл
Слайд 1108/13/2019
Варианты систем потоков данных
Трансформер – входящий поток преобразуется во внутренний
формат и обрабатывается последовательностью операций. После обработки поток преобразуется в
выходной формат.Поток транзакций – элемент потока обрабатывается согласно своему типу по собственному пути. Каждый процесс в потоке может иметь несколько выходов.
Слайд 1208/13/2019
Репозиторий
Данные содержатся в общей базе (репозитории)
Компоненты обмениваются данными неявно
Необходимы средства
синхронизации
Удобно для обмена большими объемами данных
Слайд 1308/13/2019
Виды репозиториев
Пассивный – входящий поток событий или транзакций вызывает обработку
данных в репозитории (пример - СУБД)
Активный – состояние репозитория вызывает
процессы обработки и изменения (пример – blackboard systems)
Слайд 1508/13/2019
Клиент-сервер
Модель распределенной системы, отражающая распределение данных и процессов по компонентам
Основные
компоненты:
Множество серверов, определяющих услуги, предоставляемые ПС
Множество клиентов, использующих сервисы системы
Коммуникационная
сеть для организации доступа
Слайд 1608/13/2019
Характеристики модели «клиент-сервер»
Преимущества
Простое и очевидное распределение данных
Ориентированность на сетевые среды
Простота
расширяемости (ввод новых услуг или изменение сервисов)
Недостатки
Нет общих разделяемых данных
Обмен
данными может быть неэффективнымТребуется служба имен, указывающая перечень сервисов и их размещение
Слайд 1708/13/2019
Виды модели «клиент-сервер»
«Толстый» клиент
«Толстый» сервер
Сбалансированная система
Peer2Peer
Распределенный клиент или сервер
Слайд 1808/13/2019
Разновидности серверов
Сервер без состояния – не хранит состояния соединений с
клиентами и текущих операций
Сервер с состоянием – следит за действиями
клиентов и позволяет сократить количество взаимодействий между сервером и клиентами
Слайд 1908/13/2019
Модель абстрактной машины
Описывает интерфейс между подсистемами
Представляет систему в виде набора
слоев (абстрактных машин), каждый из которых предоставляет некоторый сервис
Слои известны
извне только через свой интерфейс
Слайд 2008/13/2019
Характеристики абстрактной машины
Преимущества:
Повышение уровня абстракции – возможность легко выразить сложные
задачи
Простота сопровождения за счет изолированности слоев
Повторное использование кода
Стандартизация
Недостатки:
Сложность выделения слоев
в системахПотери производительности при большом количестве слоев
Слайд 2108/13/2019
Модели управления
Определяют потоки управления между подсистемами
Основные модели:
Централизованное управление – одна
из подсистем управляет деятельностью всех остальных
Управление на основе событий –
каждая подсистема реагирует на поступающие события, источниками которых являются другие подсистемы или внешняя среда
Слайд 2208/13/2019
Централизованное управление
Модель «вызов-возврат»
Процедурная модель, когда вызов проходит от процедур верхнего
уровня к нижнему. Применяется в последовательных системах.
Модель менеджера
Один из компонентов
определяет моменты старта, завершения и взаимодействия между остальными элементами системы.
Слайд 2308/13/2019
Управление на базе событий
Действия системы зависят от поступающих извне событий
Две
основных модели:
Широковещательная модель
Системы с прерываниями
Слайд 2408/13/2019
Широковещательная модель
Событие передается всем подсистемам
Подсистема реагирует на событие, если она
умеет его обрабатывать
Применяется коммутатор – система подписки на определенные события
Слайд 2508/13/2019
Характеристики широковещательной модели
Преимущества
Простота расширения – подсистема регистрируется в коммутаторе и
получает события
Нет нужды знать имя и расположение корреспондента
Недостатки
Неизвестно, будет
ли обработано событиеВозможен конфликт из-за наличия систем, регистрирующих одинаковые события
Слайд 2608/13/2019
Система с прерываниями
Гарантирует быстрый ответ на внешние события
Содержит независимый механизм
определения прерываний и вызова соответствующего обработчика
Обработчик может вызывать дополнительные процедуры
Слайд 2708/13/2019
Слоистая архитектура
Состоит из уровней – логически связанных коллекций элементов программного
обеспечения
Уровень скрывает свою функциональность от других и предоставляет ее через
интерфейсСистема легко модернизируется
Слайд 2808/13/2019
Архитектурные функции
Обеспечивают взаимодействие между подсистемами
Расширяют спецификацию ПС
Реализуют механизмы взаимодействия (порты,
сообщения и др.)
Слайд 2908/13/2019
Система портов
Порт – подсистема для обслуживания очереди сообщений
Имеет общесистемное обозначение
Во
многих случаях реализуется на уровне ОС
Слайд 3008/13/2019
Гибкие и жесткие порты
Жесткий порт – явно указанный системный порт
(по имени или номеру)
Гибкий порт – виртуальный порт, используемый в
программе. При запуске связывается с фиксированным жестким портом.
Слайд 3108/13/2019
Системы с сообщениями
Обеспечивают эффективное удаленное взаимодействие
Требуют наличия службы имен
Сообщения могут
быть ориентированы на пользователя
Наиболее развитая система архитектурных функций
![[Медкниги]Гарднереллез у мужчин и женщин PPT](/img/thumbs/9a447877c60cf48817648417cf34f8fd-800x.jpg)
