Лекция 4: Архитектура ПО

Frontend – это пользовательский интерфейс: сложный, параметризуемый, с рядом встроенных пользовательских сервисов (в частности, браузер информации), а также настраиваемый. Обе эти подсистемы взаимодействуют друг с другом через хорошо определенный и детально описанный программный интерфейс: алгоритмыbackend разбиты на методы, которые frontend может вызывать по особым правилам, с параметрами, выстраивая в цепочку для достижения своих задач. Дополнительные tools интегрируются во frontend, но не пользуются методами backend, а реализуют свои задачи самостоятельно. Эти задачи не требуют сложной пакетной обработки, а нацелены на интерактивное взаимодействие с пользователем.

Опеределение Архитектуры ПО:

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

Часто под архитектурой понимают например, только внутреннее устройство ПО, выраженное в UML-диаграммах.

Итак, архитектура продукта оказывается инвариантом проекта, встречается и неожиданно возникает в его разных частях.

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

Множественность точек зрения

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

1. Множественность точек зренияпроисходит, прежде всего, из-за разных видов деятельности процесса разработки ПО.

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

- При проектировании, наоборот, на первое место выходят принципы реализации ПО.

- А при тестировании детали реализации снова неважны — наПО смотрят как на черный ящик, реализующий некоторый набор пользовательской функциональности.

- При развертке у заказчика на ПО смотрят как на набор файлов, хранилищ данных и т. д.

2. Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов. Для всех этих специалистов нужна разная информация о программной системе.

3. Множественность точек зрения происходит также от того, что нет единых стандартов и норм разработки ПО.

Точка зрения (viewpoint) — это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Точку зрения нужно ясно осознавать при создании визуальных моделей, например, варианты использования. Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть, для кого она предназначается).

Язык UML:

Часто понятие архитектуры сильно сужают, понимая под ним лишь описание основных, важных аспектов ПО, создаваемых, например, архитектором при разработке дизайна системы. Для этих целей используется язык моделированияUML (UnifiedModelingLanguage).

Блок-схемы получили распространение при спецификации и документированииПО, были стандартизованы.

Виды диаграмм

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

Структурные диаграммы:

- диаграммы классов (classdiagrams) предназначены для моделирования структуры объектно-ориентированных приложений классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;

- диаграммы компонент (componentdiagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;

- диаграммы объектов (objectdiagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;

- диаграммы композитных структур (compositestructurediagrams) используются для моделирования составных структурных элементов моделей – коопераций, композитных компонент и т.д.;

- диаграммы развертывания (deploymentdiagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

- диаграммы пакетов (packagediagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

Поведенческие диаграммы:

- диаграммы активностей (activitydiagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;

- диаграммы случаев использования (usecasediagrams) предназначены для "вытягивания" требований из пользователей, заказчика и экспертов предметной области;

- диаграммы конечных автоматов (statemachinediagram) применяются для задания поведения реактивных систем;

- диаграммы взаимодействий (interactiondiagram):

- диаграммы последовательностей (sequencediagram) используются для моделирования временных аспектов внутренних и внешних протоколовПО;

- диаграммы схем взаимодействия (interactionoverviewdiagram) служат для организации иерархиидиаграмм последовательностей;

- диаграммы коммуникаций (communicationdiagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой манере);

- временные диаграммы (timingdiagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.