Глава 1. Архитектура как форма концептуального существования по

1.1. Определения архитектуры по и ее значимость

Существует множество определений понятия «архитектура ПО». Одного и безоговорочно принятого определения архитектуры не существует. Наиболее богатая коллекция вариантов употреблений этого термина представлена на сайте SEI [1], где каждому, кто считает, что он сформулировал это понятие более точно, предоставлена возможность включить его в общую коллекцию.

Мы будем придерживаться следуюшего определения.

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

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

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

Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.

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

В работе [5] предложено следующее толкование ряда позиций определения архитектуры:

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

- Архитектура определяет поведение. Архитектура определяет не только структуры системы через элементы и связи, но также и взаимодействие элементов структур, осуществляемое во времени. Для выражения динамики процессов в архитектурных описаниях используют различные средства, например «диаграммы последовательностей» на языке UML;

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

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

- Архитектура интегрирует существенные решения на основе принципов рациональности. Существенные решения и формы их интеграции в архитектуре ПО должны быть рационально представлены и обоснованы. Решения должны не только декларироваться, но и объясняться почему им было отдано предпочтение среди альтернатив;

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

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

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

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

- Архитектура имеет определенные границы. Различают архитектуру программного обеспечения, аппаратного обеспечения, информационного обеспечения; организационного обеспечения, предприятия. И всё же архитектуры ПО являются тем центром, около которого или от которого строят архитектуры других типов.