Скачать презентацию Проектирование ПО Тема 4 Архитектура приложений 14 02 Скачать презентацию Проектирование ПО Тема 4 Архитектура приложений 14 02

04 Архитектура приложений.pptx

  • Количество слайдов: 25

Проектирование ПО Тема 4. Архитектура приложений 14. 02. 2018 ИГЭУ. Кафедра ПОКС Проектирование ПО Тема 4. Архитектура приложений 14. 02. 2018 ИГЭУ. Кафедра ПОКС

Архитектура ПО «Архитектура программного обеспечения (ПО) заключает в себе ряд важных решений об организации Архитектура ПО «Архитектура программного обеспечения (ПО) заключает в себе ряд важных решений об организации программной системы, среди которых выбор структурных элементов и их интерфейсов, составляющих и объединяющих систему в единое целое; поведение, обеспечиваемое совместной работой этих элементов; организацию этих структурных и поведенческих элементов в более крупные подсистемы, а также архитектурный стиль, которого придерживается данная организация. Выбор архитектуры ПО также касается функциональности, удобства использования, устойчивости, производительности, повторного использования, понятности, экономических и технологических ограничений, эстетического восприятия и поиска компромиссов» » Филипп Крачтен (Philippe Kruchten), Грэди Буч (Grady Booch), Курт Биттнер (Kurt Bittner) и Рич Рейтман (Rich Reitman) Проектирование ПО. Архитектура приложений 2

Типовая архитектура приложения Проектирование ПО. Архитектура приложений 3 Типовая архитектура приложения Проектирование ПО. Архитектура приложений 3

Определение типа приложения Основные типы приложений: 1. Приложения для мобильных устройств. 2. Насыщенные клиентские Определение типа приложения Основные типы приложений: 1. Приложения для мобильных устройств. 2. Насыщенные клиентские приложения для выполнения преимущественно на клиентских ПК. 3. Насыщенные клиентские приложения для развертывания из Интернета с поддержкой насыщенных UI и мультимедийных сценариев. 4. Сервисы, разработанные для обеспечения связи между слабо связанными компонентами. 5. Веб-приложения для выполнения преимущественно на сервере в сценариях с постоянным подключением. Проектирование ПО. Архитектура приложений 4

1. Мобильное приложение Приложение может быть тонким Вебклиентом или насыщенным клиентом. Если создается насыщенный 1. Мобильное приложение Приложение может быть тонким Вебклиентом или насыщенным клиентом. Если создается насыщенный клиент, бизнес-слой и слой доступа к данным, скорее всего, будут располагаться на самом устройстве. Для тонкого клиента бизнес-слой и слой доступа к данным будут располагаться на сервере. Мобильные приложения обычно реализуют поддержку сценариев без подключения через использование локально кэшированных данных, синхронизация которых выполняется при установлении подключения. Они также могут использовать сервисы, предоставляемые другими приложениями, включая размещаемые сервисы и Веб-сервисы. Проектирование ПО. Архитектура приложений 5

2. Насыщенное клиентское приложение Насыщенные клиентские пользовательские интерфейсы могут обеспечить взаимодействие с пользователем с 2. Насыщенное клиентское приложение Насыщенные клиентские пользовательские интерфейсы могут обеспечить взаимодействие с пользователем с минимальным временем отклика для приложений, которые должны выполняться как самодостаточное приложение, в сценариях с подключением, без постоянного подключения и без подключения. Как правило, приложение структурировано как многослойное приложение. Приложение может использовать данные с удаленного сервера, данные, хранящиеся локально. Оно может потреблять сервисы, предоставляемые другими приложениями, включая размещаемые сервисы типа S+S и Веб-сервисы. Проектирование ПО. Архитектура приложений 6

3. Насыщенное Интернет-приложение Проектирование ПО. Архитектура приложений Насыщенное Интернет-приложение (RIA) выполняется в браузере. К 3. Насыщенное Интернет-приложение Проектирование ПО. Архитектура приложений Насыщенное Интернет-приложение (RIA) выполняется в браузере. К преимуществам RIA, по сравне-нию с традиционными Веб-приложениями, относятся более насыщенный пользовательский интерфейс, улучшенное время отклика приложения и эффективность работы с сетью. Как правило, RIA структурировано как многослойное приложение. Как правило, RIAприложения зависят от подключаемого модуля на стороне клиента или размещаемой среды выполнения (Flash, Java, XAML или Silverlight). Подключаемый модуль взаимодействует с Веб-сервером, который формирует код и данные, потребляемые клиентским подключаемым модулем или средой выполнения. 7

4. Сервис Проектирование ПО. Архитектура приложений Сервис – это открытый интерфейс, обеспечивающий доступ к 4. Сервис Проектирование ПО. Архитектура приложений Сервис – это открытый интерфейс, обеспечивающий доступ к единице функциональности. Сервис, фактически, предоставляет программный сервис вызывающей стороне, которая потребляет этот сервис. Как правило, сервисное приложение, предоставляющее такие сервисы, структурировано как многослойное приложение. Сервисы слабо связаны и могут сочетаться для обеспечения более сложной функциональности. Сервисы могут быть распределенными, доступ к сервису может осуществляться как удаленно, так и с компьютера, на котором сервис выполняется. Также сервисы ориентируются на обмен сообщениями. Это означает, что интерфейсы описываются WSDLдокументом, и операции вызываются с помощью построенных на XML-схемах 8 сообщений, которые передаются по

5. Веб-приложение Ядро Веб-приложения – его логика на стороне сервера. Эта логика может состоять 5. Веб-приложение Ядро Веб-приложения – его логика на стороне сервера. Эта логика может состоять из множества отдельных слоев. Типовым примером является трехслойная архитектура. Как правило, Веб-приложение осуществляет доступ к хранилищу данных на удаленном сервере базы данных. Также оно может потреблять сервисы, предоставляемые другими приложениями, включая размещаемые сервисы типа S+S и Веб-сервисы. Проектирование ПО. Архитектура приложений 9

Выбор стратегии развертывания На архитектуру приложения могут влиять ограничения развертывания: • физическое распределение компонентов Выбор стратегии развертывания На архитектуру приложения могут влиять ограничения развертывания: • физическое распределение компонентов по серверам, • ограничение по используемым сетевым протоколам, • настройки межсетевых экранов и маршрутизаторов и многое другое. Проектирование ПО. Архитектура приложений 10

Выбор соответствующих технологий Ключевым фактором при выборе технологий для приложения является тип разрабатываемого приложения, Выбор соответствующих технологий Ключевым фактором при выборе технологий для приложения является тип разрабатываемого приложения, а также предпочтительные варианты топологии развертывания приложения и архитектурные стили. Выбор технологий также определяется политиками организации, ограничениями среды и т. д. Необходимо сравнить возможности выбираемых технологий с требованиями приложения, принимая во внимание все эти факторы. Проектирование ПО. Архитектура приложений 11

Выбор показателей качества Факторы качества ПО (ГОСТ 28195): • надежность, • сопровождаемость, • удобство Выбор показателей качества Факторы качества ПО (ГОСТ 28195): • надежность, • сопровождаемость, • удобство применения, • эффективность, • универсальность • корректность. Требования и сценарии развертывания определяют какие показатели качества важны для архитектуры создаваемого приложения. Нельзя также забывать о возможности конфликта между показателями качества. Например, часто требования безопасности идут вразрез с производительностью или удобством использования. Проектирование ПО. Архитектура приложений 12

Реализация сквозной функциональности Аспекты сквозной функциональности, которые необходимо рассмотреть: • Протоколирование. Нужно обеспечить мониторинг Реализация сквозной функциональности Аспекты сквозной функциональности, которые необходимо рассмотреть: • Протоколирование. Нужно обеспечить мониторинг всех критически важных для системы событий. Протоколируется достаточное количество сведений для воссоздания событий в системе без включения конфиденциальных данных. • Аутентификация. Определяется как будет проходить аутентификация и передача удостоверений между слоями. • Авторизация обеспечивается на каждом уровне и между границами доверия. • Управление исключениями. Перехватываются исключения на функциональных, логических и физических границах. • Связь. Выбираются соответствующие протоколы; сводится до минимума количество вызовов по сети; обеспечивается защита передаваемых конфиденциальных данных по сети. • Кэширование. Требуется определить, что должно кэшироваться для улучшения производительности и сокращения времени отклика. При проектировании кэширования нужно учесть особенности Веб-фермы и фермы приложений. Проектирование ПО. Архитектура приложений 13

Архитектурные шаблоны и стили Архитектурные паттерны (Architectural patterns) предназначены для спецификации фундаментальных схем структуризации Архитектурные шаблоны и стили Архитектурные паттерны (Architectural patterns) предназначены для спецификации фундаментальных схем структуризации программных систем. Архитектурные стили/парадигмы: 1. Объектно-ориентированная 2. Компонентная архитектура 3. Проектирование на основе предметной области 4. Многослойная архитектура 5. Аспектно-ориентированная 6. Клиент-сервер 7. N-уровневая / 3 -уровневая 8. Сервисно-оринетрированная архитектура (SOA) 9. Шина сообщений Проектирование ПО. Архитектура приложений 14

Объектно-ориентированная архитектура – это парадигма проектирования, основанная на разделении ответственностей приложения на самостоятельные пригодные Объектно-ориентированная архитектура – это парадигма проектирования, основанная на разделении ответственностей приложения на самостоятельные пригодные для повторного использования объекты, каждый из которых содержит данные и поведение, относящиеся к этому объекту. Основные принципы: 1. Абстракция. Позволяет преобразовать сложную операцию в обобщение, сохраняющее основные характеристики операции. 2. Композиция. Объекты могут быть образованы другими объектами. 3. Наследование. Объекты могут наследоваться от других объектов и использовать функциональность базового объекта или переопределять ее для реализации нового поведения. 4. Инкапсуляция. Объекты предоставляют функциональность только через методы, свойства и события и скрывают внутренние детали. 5. Полиморфизм. Позволяет переопределять поведение базового типа, поддерживающего операции в приложении. 6. Отделение. Объекты могут быть отделены от потребителя путем определения абстрактного интерфейса. Проектирование ПО. Архитектура приложений 15

Компонентная архитектура Виды компонентов: • компоненты пользовательского интерфейса; • ресурсоемкие компоненты (удаленные или распределенные Компонентная архитектура Виды компонентов: • компоненты пользовательского интерфейса; • ресурсоемкие компоненты (удаленные или распределенные компоненты); • компоненты с очередью; TTable TData. Source TDBGrid Таблица Источник данных Объектная модель программных компонентов (component object model, COM). Объектная модель распределенных программных компонентов (distributed component object model, DCOM). Общая архитектура брокера объектных запросов (Common Object Request Broker Architecture, CORBA). Серверные компоненты Java (Enterprise Java. Beans, EJB). Таблица БД • • Проектирование ПО. Архитектура приложений 16

Проектирование на основе предметной области (Domain Driven Design, DDD) – это набор принципов и Проектирование на основе предметной области (Domain Driven Design, DDD) – это набор принципов и схем, помогающих разработчикам создавать системы объектов. Оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями области применения продукта и кодом. Сутью DDD является конкретное определение контекстов и ограничение моделирования в их рамках. Предметная область моделируется сущностями (единицами поведения). В коде используется язык предметной области. У сущностей есть и индивидуальность, и жизненный цикл. Выделяются специальные сущности — сводные корни, к которым напрямую обращаются потребители. Есть объекты-значения, которые после создания уже не изменяются. Операции или процессы, у которых нет обозначения или жизненного цикла представляются службами. В разработке используется автотестирование. Actifsource плагин для Eclipse, который позволяет разработчикам создавать продукт с управляемыми моделями и генератором кода. Проектирование ПО. Архитектура приложений 17

Многослойная архитектура Слой (layer) обозначает логическое разделение функциональности. Уровень (tier) физическое разворачивание на разных Многослойная архитектура Слой (layer) обозначает логическое разделение функциональности. Уровень (tier) физическое разворачивание на разных системах. Группа паттернов Отделение представления (Separated Presentation ) <> Boundary <> View <> Controller MVC <> Слой-представление <> Controller <> Бизнес-слой <> Entity <> Model <> Слой работы с данными UML Проектирование ПО. Архитектура приложений 18

Аспектно-ориентированное программирование (АОП) — парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения Аспектно-ориентированное программирование (АОП) — парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения программы на модули. Группой инженеров исследовательского центра Xerox PARC в 2001 году было разработано аспектно-ориентированное расширение для языка Java, получившее название Aspect. J. Такое же расширение есть для C# - Post. Sharp (Gael Fraiteur). Популярна также система Aspect. NET, автор: Сафонов Владимир Олегович (СПб. ГУ). Проектирование ПО. Архитектура приложений Грегор Кичалес (Gregor Kiczales) 19

Пример АОП а) public class Person : INotify. Property. Changed { private string first. Пример АОП а) public class Person : INotify. Property. Changed { private string first. Name; private string last. Name; public event Property. Changed. Event. Handler Property. Changed; protected virtual void On. Property. Changed(string property. Name) { if ( this. Property. Changed != null ) { this. Property. Changed( this, new Property. Changed. Event. Args(property. Name) ); } } public string First. Name { get { return this. first. Name; } set { if ( this. first. Name != value ) { this. first. Name = value; this. On. Property. Changed("First. Name"); this. On. Property. Changed("Full. Name"); } } public string Last. Name { get { return this. last. Name; } set { if ( this. last. Name != value ) { this. last. Name = value; this. On. Property. Changed("Last. Name"); this. On. Property. Changed("Full. Name"); } } public string Full. Name { get { return this. First. Name + " " + this. Last. Name; } } } Проектирование ПО. Архитектура приложений б) [Notify. Property. Changed] public class Person { public string First. Name { get; set; } public string Last. Name { get; set; } public string Full. Name { get { return this. First. Name + " " + this. Last. Name; } } } Листинги программ: а) С#; б) Post. Sharp. 20

Основные понятия АОП Аспект (aspect) — модуль или класс, реализующий сквозную функциональность. Аспект изменяет Основные понятия АОП Аспект (aspect) — модуль или класс, реализующий сквозную функциональность. Аспект изменяет поведение остального кода, применяя совет в точках соединения, определённых некоторым срезом. Аспект - это модуль, применение которого осуществляется не путем вызова, а путем систематизированного внедрения фрагментов кода аспекта в модули программы. Совет (advice) — средство оформления кода, который должен быть вызван из точки соединения. Совет может быть выполнен до, после или вместо точки соединения. Точка соединения (join point) — точка в выполняемой программе, где следует применить совет, например, вызов метода или обращение к полям объекта. Срез (pointcut) — набор точек соединения. Срез определяет, подходит ли данная точка соединения к данному совету. Внедрение (introduction) — изменение структуры класса или изменение иерархии наследования для добавления функциональности аспекта. При запуске подсистема внедрения аспектов, используя правила внедрения, определяет конкретные, удовлетворяющие условиям точки соединения аспекта в коде программы, куда затем и добавляет действия аспекта. Проектирование ПО. Архитектура приложений 21

Архитектура клиент-сервер (client-server) Системы с одним сервером Клиент 1 Клиент 2 … Системы с Архитектура клиент-сервер (client-server) Системы с одним сервером Клиент 1 Клиент 2 … Системы с множеством серверов Клиент N Клиент 1 Сервер БД Сервер каталогов (клиент-сервер, файл-сервер, хранилище данных) Системы клиент-очередь-клиент Клиент 1 Клиент 2 … Одноранговые приложения (P 2 P) Клиент (сервер) 2 Клиент N Клиент 2 Сервер видео … Клиент N Сервер фото Серверы приложений Терминал 1 Терминал 2 … Терминал N Клиент (сервер) 1 Очередь Клиент (сервер) 3 Проектирование ПО. Архитектура приложений Служба терминалов 22

N-уровневая / 3 -уровневая архитектура <<Web-server>> Представление <<Firewall>> Межсетевой экран <<Web-server>> Бизнес-слой ASP <<Server>> N-уровневая / 3 -уровневая архитектура <> Представление <> Межсетевой экран <> Бизнес-слой ASP <> СУБД Финансовое Веб-приложение Проектирование ПО. Архитектура приложений 23

Сервисно-ориентированная архитектура (Service-oriented architecture, SOA) Принципы SOA: 1. Сервисы автономны. 2. Сервисы могут быть Сервисно-ориентированная архитектура (Service-oriented architecture, SOA) Принципы SOA: 1. Сервисы автономны. 2. Сервисы могут быть распределены. Сервисы слабо сцеплены. 3. Сервисы совместно используют схему и контракт, но не класс. 4. Совместимость основана на политике. ПО + сервисы (Software plus Services, S+S) Проектирование ПО. Архитектура приложений ПО как сервис (Software as a Service, Saa. S) 24

Архитектура, основанная на шине сообщений Основной принцип сервисной шины — концентрация обмена сообщениями между Архитектура, основанная на шине сообщений Основной принцип сервисной шины — концентрация обмена сообщениями между различными системами через единую точку, в которой, при необходимости, обеспечивается транзакционный контроль, преобразование данных, сохранность сообщений. Все настройки обработки и передачи сообщений предполагаются также сконцентрированными в единой точке, и формируются в терминах служб, таким образом, при замене какой-либо информационной системы, подключённой к шине, нет необходимости в перенастройке остальных систем. Сервисная шина предприятия (Enterprise Service Bus, ESB). Шина Интернет-сервисов (Internet Service Bus, ISB). Проектирование ПО. Архитектура приложений 25