1.2. Место архитектурных решений
Содержание определений архитектуры явно и неявно указывает на место архитектурных решений и их роль в разработке ПО.
В современной практике разработки ПО широко используется спирально-итеративная модель жизненного цикла, что приводит к необходимости возврата к вопросам разработки архитектуры с каждым циклом спирали (Рис. 1).
Рисунок 1. Спиралевидный процесс разработки
В процессе разработки ПО границы между этапами жизненного цикла и итерациями в рамках одного и того же этапа «размыты». Это особенно типично для этапов анализа требований (результатом которого является Система Требований - СТ) и разработки архитектуры (результатом которого является Архитектурное Описание - АО). Каждый из этапов «анализа» и «архитектуры» приводит к определенной форме существования ПО в рамках его жизненного цикла, что показано на рис. 2.
Рисунок 2. Архитектура, как форма концептуального существования ПО
На рисунке показано, что формы существования ПО на ранних этапах разработки являются концептуальными, то есть представляют собой связную совокупность текстовых (в том числе табличных) документов, графических моделей и диаграмм (часто использующих для своего представления язык UML).
Повторимся - не существует четкого разграничения понятия архитектурного программирования и реализации ПО. Часть перечисленных пунктов может быть и не отнесена к категории архитектура. Так же как и некоторые формулировки принципов модульного программирования и ООП могут быть отнесены к архитектурным решениям. Но самое главное требование к архитектуре - расширяемость - масштабируемость. Если ее нет - то это не архитектурное решение.
Например, стиль приложения клиент-сервер считается архитектурным стилем (стратегическим дизайном), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.
Архитектура является проектированием (дизайном), но не всякий дизайн является архитектурным дизайном. На практике, архитектор определяет грань между архитектурой программного обеспечения (архитектурным дизайном) и детальным дизайном (неархитектурным проектированием).
Являясь в настоящий момент своего развития дисциплиной без четких правил, проектирование архитектуры ПО все ещё является смесью науки, искусства и «магии».
Аспект «искусства-магии» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. То, как сформулированы ключевые цели системы, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющие, как будет вести себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость, надежность, пригодность к сервисному обслуживанию, доступность, безопасность, удобство использования, и пр.
С точки зрения пользователя программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей.
В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения, является аргументом в защиту необходимости и целесообразности создания архитектуры ПО ещё до этапа разработки ПО.