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

в себе ряд важных решений об организации программной системы, среди которых:
выбор структурных элементов и их интерфейсов, составляющих и объединяющих систему в единое целое;
поведение, обеспечиваемое совместной работой этих элементов;
организацию этих структурных и поведенческих элементов в более крупные подсистемы, а также
архитектурный стиль, которого придерживается данная организация.
Выбор архитектуры ПО также касается функциональности, удобства использования, устойчивости, производительности, повторного использования, понятности, экономических и технологических ограничений, эстетического восприятия и поиска компромиссов».

Филипп Крачтен (Philippe Kruchten), Грэди Буч (Grady Booch),
Курт Биттнер (Kurt Bittner) и Рич Рейтман (Rich Reitman)

мобильных устройств.
Насыщенные клиентские приложения для выполнения преимущественно на клиентских ПК.
Насыщенные Интернет-приложения (RIA, Rich Internet Application).
Сервисы, разработанные для обеспечения связи между слабо связанными компонентами.
Веб-приложения для выполнения преимущественно на сервере в сценариях с постоянным подключением.

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

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

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

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

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

развертывания:
физическое распределение компонентов по серверам,
ограничение по используемым сетевым протоколам,
настройки межсетевых экранов и маршрутизаторов и многое другое.

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

удобство применения,
эффективность,
универсальность
корректность.

Нельзя также забывать о возможности конфликта между показателями качества. Например, часто требования безопасности идут вразрез с производительностью или удобством использования.

Требования и сценарии развертывания определяют какие показатели качества важны для архитектуры создаваемого приложения.

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

архитектура
3. Проектирование на основе предметной области
4. Многослойная архитектура
5. Аспектно-ориентированная
6. Клиент-сервер
7. N-уровневая / 3-уровневая
8. Сервисно-оринетрированная архитектура (SOA)
9. Шина сообщений

Архитектурные паттерны (Architectural patterns) предназначены для спецификации фундаментальных схем структуризации программных систем.

на разделении ответственностей приложения на само-стоятельные пригодные для повторного использования объекты, каждый из которых содержит данные и поведение, относящиеся к этому объекту.

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

или распределенные компоненты);
компоненты с очередью;

TTable

TDataSource

TDBGrid

Таблица БД

Источник данных

Таблица

Объектная модель программных компонентов (component object model, COM).
Объектная модель распределенных программных компонентов (distributed component object model, DCOM).
Общая архитектура брокера объектных запросов (Common Object Request Broker Architecture, CORBA) .
Серверные компоненты Java (Enterprise JavaBeans, EJB) .

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

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

разделение функциональности.
Уровень (tier) физическое разворачивание на разных системах.

Группа паттернов Отделение представления (Separated Presentation )

<>
Boundary

<>
Controller

<>
Entity

<>
Model

<>
View

<>
Controller

MVC

UML

парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения программы на модули.

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

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.

а)

б)

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

с множеством серверов

Системы
с одним сервером

Клиент 1

Клиент 2

Клиент N

…

Сервер БД

Клиент 1

Клиент 2

Клиент N

…

Сервер видео

Сервер каталогов

Сервер фото

Клиент 1

Клиент 2

Клиент N

…

Очередь

Клиент (сервер) 1

Клиент (сервер) 2

Клиент (сервер) 3

Терминал 1

Терминал 2

Терминал N

…

Служба терминалов

(клиент-сервер, файл-сервер, хранилище данных)

могут быть распределены. Сервисы слабо сцеплены.
Сервисы совместно используют схему и контракт, но не класс.
Совместимость основана на политике.

ПО + сервисы
(Software plus Services, S+S)

ПО как сервис
(Software as a Service, SaaS)