Тема 4. Архитектура приложений 08.09.2013 ИГЭУ. Кафедра ПОКС
Проектирование ПО. Архитектура приложений 2 Архитектура ПО ( software architecture ) «Архитектура программного обеспечения (ПО) заключает в себе ряд важных решений об организации программной системы, среди которых: выбор структурных элементов и их интерфейсов, составляющих и объединяющих систему в единое целое; поведение, обеспечиваемое совместной работой этих элементов; организацию этих структурных и поведенческих элементов в более крупные подсистемы, а также архитектурный стиль, которого придерживается данная организация. Выбор архитектуры ПО также касается функциональности, удобства использования, устойчивости, производительности, повторного использования, понятности, экономических и технологических ограничений, эстетического восприятия и поиска компромиссов ». Филипп Крачтен ( Philippe Kruchten ), Грэди Буч ( Grady Booch ), Курт Биттнер ( Kurt Bittner ) и Рич Рейтман ( Rich Reitman )
Проектирование ПО. Архитектура приложений 3 Типовая архитектура приложения
Проектирование ПО. Архитектура приложений 4 Определение типа приложения О сновные типы приложений: Приложения для мобильных устройств. Насыщенные клиентские приложения для выполнения преимущественно на клиентских ПК. Насыщенные Интернет-приложения (RIA, Rich Internet Application). Сервисы, разработанные для обеспечения связи между слабо связанными компонентами. Веб-приложения для выполнения преимущественно на сервере в сценариях с постоянным подключением.
Проектирование ПО. Архитектура приложений 5 1. Мобильное приложение Приложение может быть тонким Веб-клиентом или насыщенным клиентом. Если создается насыщенный клиент, бизнес-слой и слой доступа к данным, скорее всего, будут располагаться на самом устройстве. Для тонкого клиента бизнес-слой и слой доступа к данным будут располагаться на сервере. Мобильные приложения обычно реализуют поддержку сценариев без подключения через использование локально кэшированных данных, синхронизация которых выполняется при установлении подключения. Они также могут использовать сервисы, предоставляемые другими приложениями, включая размещаемые сервисы ( S+S ) и Веб-сервисы.
Проектирование ПО. Архитектура приложений 6 2. Насыщенное клиентское приложение Насыщенные клиентские пользовательские интерфейсы могут обеспечить взаимодействие с пользователем с минимальным временем отклика для приложений, которые должны выполняться как самодостаточное приложение, в сценариях с подключением, без постоянного подключения и без подключения. Как правило, приложение структурировано как многослойное приложение. Приложение может использовать данные с удаленного сервера, данные, хранящиеся локально. Оно может потреблять сервисы, предоставляемые другими приложениями, включая размещаемые сервисы типа S+S и Веб-сервисы.
Проектирование ПО. Архитектура приложений 7 3. Насыщенное Интернет-приложение Насыщенное Интернет- приложе - ние (RIA) выполняется в браузере. К преимуществам RIA, по сравне-нию с традиционными Веб- прило - жениями, относятся более насы -щенный пользовательский интер-фейс, улучшенное время отклика приложения и эффективность работы с сетью. Как правило, RIA структурировано как многослойное приложение. Как правило, RIA-приложения зависят от подключае-мого модуля на стороне клиента или размещаемой среды выполне-ния ( Flash, Java, XAML или Silver-light ). Подключаемый модуль взаимодействует с Веб-сервером, который формирует код и данные, потребляемые клиентским под- ключаемым модулем или средой выполнения.
Проектирование ПО. Архитектура приложений 8 4. Сервис Сервис – это открытый интерфейс, обеспечивающий доступ к единице функциональности. Сервис, фактически, предоставляет программный сервис вызывающей стороне, которая пот - ребляет этот сервис. Сервисы слабо сцеплены и могут сочетаться для обес - печения более сложной функциональ - ности. Сервисы могут быть распреде - ленными, доступ к сервису может осуществляться как удаленно, так и с компьютера, на котором сервис вы - полняется. Сервисы ориентируются на обмен сообщениями. Это означает, что интерфейсы описываются WSDL-доку-ментом, и операции вызываются с помощью построенных на XML-схемах сообщений, которые передаются по транспортному каналу.
Проектирование ПО. Архитектура приложений 9 5. Веб-приложение Ядро Веб-приложения – его логика на стороне сервера. Эта логика может состоять из множества отдельных слоев. Типовым примером является трехслойная архитектура. Как правило, Веб-приложение осуществляет доступ к хранилищу данных на удаленном сервере базы данных. Также оно может потреблять сервисы, предоставляемые другими приложениями, включая размещаемые сервисы типа S+S и Веб-сервисы.
Проектирование ПО. Архитектура приложений 10 Выбор стратегии развертывания На архитектуру приложения могут влиять ограничения развертывания: физическое распределение компонентов по серверам, ограничение по используемым сетевым протоколам, настройки межсетевых экранов и маршрутизаторов и многое другое.
Проектирование ПО. Архитектура приложений 11 Выбор соответствующих технологий Ключевым фактором при выборе технологий для приложения является тип разрабатываемого приложения, а также предпочтительные варианты топологии развертывания приложения и архитектурные стили. Выбор технологий также определяется политиками организации, ограничениями среды и т.д. Необходимо сравнить возможности выбираемых технологий с требованиями приложения, принимая во внимание все эти факторы.
Проектирование ПО. Архитектура приложений 12 Выбор показателей качества Факторы качества ПО (ГОСТ 28195 ): надежность, с опровождаемость, удобство применения, э ффективность, у ниверсальность к орректность. Нельзя также забывать о возможности конфликта между показателями качества. Например, часто требования безопасности идут вразрез с производительностью или удобством использования. Требования и сценарии развертывания определяют какие показатели качества важны для архитектуры создаваемого приложения.
Проектирование ПО. Архитектура приложений 13 Реализация сквозной функциональности Аспекты сквозной функциональности, которые необходимо рассмотреть: Протоколирование. Нужно обеспечить мониторинг всех критически важных для системы событий. Протоколируется достаточное количество сведений для воссоздания событий в системе без включения конфиденциальных данных. Аутентификация. Определяется как будет проходить аутентификация и передача удостоверений между слоями. Авторизация. Авторизация обеспечивается на каждом уровне и между границами доверия. Управление исключениями. Перехватываются исключения на функциональных, логических и физических границах. Связь. Выбираются соответствующие протоколы; сводится до минимума количество вызовов по сети; обеспечивается защита передаваемых конфиденциальных данных по сети. Кэширование. Требуется определить, что должно кэшироваться для улучшения производительности и сокращения времени отклика. При проектировании кэширования нужно учесть особенности Веб-фермы и фермы приложений.
Проектирование ПО. Архитектура приложений 14 Архитектурные шаблоны и стили Архитектурные стили/парадигмы: 1. Объектно-ориентированная 2. Компонентная архитектура 3. Проектирование на основе предметной области 4. Многослойная архитектура 5. Аспектно -ориентированная 6. Клиент-сервер 7. N-уровневая / 3-уровневая 8. Сервисно-оринетрированная архитектура (SOA) 9. Шина сообщений Архитектурные паттерны ( Architectural patterns ) предназначены для спецификации фундаментальных схем структуризации программных систем.
Проектирование ПО. Архитектура приложений 15 Объектно-ориентированная архитектура Объектно-ориентированная архитектура – это парадигма проектиро-вания, основанная на разделении ответственностей приложения на само- стоятельные пригодные для повторного использования объекты, каждый из которых содержит данные и поведение, относящиеся к этому объекту. Основные принципы: Абстракция. Позволяет преобразовать сложную операцию в обобщение, сохраняющее основные характеристики операции. Композиция. Объекты могут быть образованы другими объектами. Наследование. Объекты могут наследоваться от других объектов и использовать функциональность базового объекта или переопределять ее для реализации нового поведения. Инкапсуляция. Объекты предоставляют функциональность только через методы, свойства и события и скрывают внутренние детали. Полиморфизм. Позволяет переопределять поведение базового типа, поддерживающего операции в приложении. Отделение. Объекты могут быть отделены от потребителя путем определения абстрактного интерфейса.
Проектирование ПО. Архитектура приложений 16 Компонентная архитектура Виды компонентов: компоненты пользовательского интерфейса; ресурсоемкие компоненты (удаленные или распределенные компоненты); компоненты с очередью; TTable TDataSource TDBGrid Таблица БД Источник данных Таблица Объектная модель программных компонентов ( component object model, COM ). Объектная модель распределенных программных компонентов ( distributed component object model, DCOM ). Общая архитектура брокера объектных запросов ( Common Object Request Broker Architecture, CORBA ). Серверные компоненты Java ( Enterprise JavaBeans, EJB ).
Проектирование ПО. Архитектура приложений 17 Проектирование на основе предметной области Проектирование на основе предметной области ( Domain Driven Design, DDD ) – это набор принципов и схем, помогающих разработчикам создавать системы объектов. Оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями области применения продукта и кодом. Сутью DDD является конкретное определение контекстов и ограничение моделирования в их рамках. Предметная область моделируется сущностями (единицами поведения). В коде используется язык предметной области. У сущностей есть и индивидуальность, и жизненный цикл. Выделяются специальные сущности — сводные корни, к которым напрямую обращаются потребители. Есть объекты-значения, которые после создания уже не изменяются. Операции или процессы, у которых нет обозначения или жизненного цикла представляются службами. В разработке используется автотестирование. Actifsource плагин для Eclipse, который позволяет разработчикам создавать продукт с управляемыми моделями и генератором кода.
Проектирование ПО. Архитектура приложений 18 Многослойная архитектура <<layer>> Слой-представление <<layer>> Бизнес-слой <<layer>> Слой работы с данными Слой ( layer ) обозначает логическое разделение функциональности. Уровень ( tier ) физическое разворачивание на разных системах. Группа паттернов Отделение представления ( Separated Presentation ) <<layer>> Boundary <<layer>> Controller <<layer>> Entity <<layer>> Model <<layer>> View <<layer>> Controller MVC UML
Проектирование ПО. Архитектура приложений 19 Аспектно -ориентированное программирование Грегор Кичалес ( Gregor Kiczales ) Аспектно -ориентированное программирование (АОП) — парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения программы на модули. Группой инженеров исследовательского центра Xerox PARC в 2001 году было разработано аспектно -ориентированное расширение для языка Java, получившее название AspectJ. Такое же расширение есть для C # - PostSharp ( Gael Fraiteur ). Популярна также система Aspect.NET, автор: Сафонов Владимир Олегович (СПбГУ).
Проектирование ПО. Архитектура приложений 20 Пример АОП public class Person : INotifyPropertyChanged { private string firstName ; private string lastName ; public event PropertyChangedEventHandler PropertyChanged ; protected virtual void OnPropertyChanged (string propertyName ) { if ( this.PropertyChanged != null ) { this.PropertyChanged ( this, new PropertyChangedEventArgs ( propertyName ) ); } } public string FirstName { get { return this.firstName ; } set { if ( this.firstName != value ) { this.firstName = value; this.OnPropertyChanged (" FirstName "); this.OnPropertyChanged (" FullName "); } } } public string LastName { get { return this.lastName ; } set { if ( this.lastName != value ) { this.lastName = value; this.OnPropertyChanged (" LastName "); this.OnPropertyChanged (" FullName "); } } } public string FullName { get { return this.FirstName + " " + this.LastName ; } } } [ NotifyPropertyChanged ] public class Person { public string FirstName { get; set; } public string LastName { get; set; } public string FullName { get { return this.FirstName + " " + this.LastName ; } } } Листинги программ: а) С # ; б) PostSharp. а) б)
Проектирование ПО. Архитектура приложений 21 Основные понятия АОП Аспект ( aspect ) — модуль или класс, реализующий сквозную функциональ-ность. Аспект изменяет поведение остального кода, применяя совет в точках соединения, определённых некоторым срезом. Аспект - это модуль, примене-ние которого осуществляется не путем вызова, а путем систематизированного внедрения фрагментов кода аспекта в модули программы. Совет ( advice ) — средство оформления кода, который должен быть вызван из точки соединения. Совет может быть выполнен до, после или вместо точки соединения. Точка соединения ( join point ) — точка в выполняемой программе, где следует применить совет, например, вызов метода или обращение к полям объекта. Срез ( pointcut ) — набор точек соединения. Срез определяет, подходит ли данная точка соединения к данному совету. Внедрение ( introduction ) — изменение структуры класса или изменение иерархии наследования для добавления функциональности аспекта. При запуске подсистема внедрения аспектов, используя правила внедрения, определяет конкретные, удовлетворяющие условиям точки соединения аспекта в коде программы, куда затем и добавляет действия аспекта.
Проектирование ПО. Архитектура приложений 22 Архитектура клиент-сервер ( client-server ) Системы клиент-очередь-клиент Одноранговые приложения ( P2P ) Серверы приложений Системы с множеством серверов Системы с одним сервером Клиент 1 Клиент 2 Клиент N … Сервер БД Клиент 1 Клиент 2 Клиент N … Сервер видео Сервер каталогов Сервер фото Клиент 1 Клиент 2 Клиент N … Очередь Клиент (сервер) 1 Клиент (сервер) 2 Клиент (сервер) 3 Терминал 1 Терминал 2 Терминал N … Служба терминалов (клиент-сервер, файл-сервер, хранилище данных)
Проектирование ПО. Архитектура приложений 23 N-уровневая / 3-уровневая архитектура ASP Финансовое Веб-приложение <<Web-server>> Представление <<Web-server>> Бизнес-слой << S erver >> СУБД <<Firewall>> Межсетевой экран
Проектирование ПО. Архитектура приложений 24 Сервисно -ориентированная архитектура ( Service-oriented architecture, SOA ) Принципы SOA: Сервисы автономны. Сервисы могут быть распределены. Сервисы слабо сцеплены. Сервисы совместно используют схему и контракт, но не класс. Совместимость основана на политике. ПО + сервисы ( Software plus Services, S+S ) ПО как сервис ( Software as a Service, SaaS )
Проектирование ПО. Архитектура приложений 25 Архитектура, основанная на шине сообщений Сервисная шина предприятия (Enterprise Service Bus, ESB ). Шина Интернет - сервисов (Internet Service Bus, ISB ). Основной принцип сервисной шины — концентрация обмена сообщениями между различными системами через единую точку, в которой, при необходимости, обеспечивается транзакционный контроль, преобразование данных, сохранность сообщений. Все настройки обработки и передачи сообщений предполагаются также сконцентрированными в единой точке, и формируются в терминах служб, таким образом, при замене какой-либо информационной системы, подключённой к шине, нет необходимости в перенастройке остальных систем.
