Что такое архитектура программного обеспечения? Важность архитектуры программного обеспечения Разработчики структуры программного обеспечения Навыки для разработчика программного обеспечения Литература

Виды (views)

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Примеры видов:
Функциональный/логический вид
Вид код/модуль
Вид разработки (development)/структурный
Вид параллельности выполнения/процесс/поток
Физический вид/вид развертывания
Вид с точки зрения действий пользователя
Вид с точки зрения данных
Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.


Базовые фреймворки для архитектуры ПО (software architecture frameworks)

Существуют следующие фреймворки, относящихся к области архитектуры ПО:

4+1
RM-ODP (Reference Model of Open Distributed Processing)
Service-Oriented Modeling Framework (SOMF)
Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).


2. В чем важность архитектуры программного обеспечения?

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

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

3. Чем занимаются разработчики архитектуры программного обеспечения?

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

Разработчик архитектуры программного обеспечения должен учитывать потребности клиента. Однако общий термин «клиент» обычно состоит из трех противоречащих областей ответственности: бизнес-требования, требования пользователя и системные требования. Бизнес-требования обычно определяют диапазон таких факторов, как бизнес-процессы, факторы производительности (такие как безопасность, надежность и пропускная способность), а также бюджетные ограничения и ограничения на издержки. Требования пользователя включают в себя дизайн интерфейса, производственные возможности и простоту использования программного обеспечения. Системные требования подразумевают возможности и ограничения оборудования, сети и среды выполнения. На рис. 1 показано, как могут различаться эти различные требования, поэтому разработчику необходимо создать архитектуру, подходящую для перекрывающихся областей.

Рис. 1. — конфликтные требования типичного клиента

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

Последний вопрос одновременно важен и интересен. Хорошая архитектура программного обеспечения не только соответствует текущим требованиям клиентов, но и будет соответствовать таким требованиям в обозримом будущем. Это влияет на решения, принимаемые разработчиком архитектуры относительно оборудования, компонентов, платформ, сред выполнения, программных систем управления и множества других функций, встроенных в программное обеспечение или с которыми оно должно интегрироваться.
Как и большинство заданий в мире проектирования и разработки программного обеспечения, разработка архитектуры — это одновременно предупредительный и итеративный процесс. Многие первоначальные задачи, такие как анализ требований, техническое исследование и определение целей, обычно выполняются в начале процесса. Следующий этап — определение ключевых сценариев для архитектуры. Это основные требования, которым должно соответствовать программное обеспечение, и ограничения, в рамках которых оно должно работать. На основании этой информации разработчик архитектуры может создать обзор приложения. Этот обзор охватывает такие высокоуровневые сведения, как тип приложения (для Интернета, телефонов, настольное или облачное), архитектура развертывания (обычно многоуровневая архитектура, компоненты которой связываются через границы оборудования и сети), соответствующие применимые стили архитектуры (например, n-уровневая, клиент-сервер или сервис-ориентированная) и технологии реализации, лучше всего подходящие для сценария.
После этого разработчик может приступить к созданию кандидатов архитектуры, удовлетворяющих высокоуровневым и наиболее важным требованиям, определенным ранее. После этого проект архитектуры проверяется и тестируется в ключевых сценариях, часто в сочетании с отзывами клиентов и пробными или тестовыми версиями, для обеспечения получения оптимального результата. Это маловероятно при первой итерации, но при повторении цикла будет достигнуто соответствие проекта требованиям и ключевым сценариям. На рис. 2 показан этот поэтапный подход.



Рис. 2. — поэтапный процесс архитектурного проектирования

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

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