-
Необходимость архитектуры
Для того чтобы у разработчиков складывалась единая концепция большой и сложной программной системы, необходим архитектор. Сложно представить себе программную систему, не существующую в нашем трехмерном мире. Программные системы часто бывают в какой-то степени беспрецедентны или уникальны. Нередко они используют прогрессивные технологии или новое сочетание технологий. Часто они используют существующие технологии на пределе их возможностей. Кроме этого, они должны быть построены так, чтобы адаптироваться к огромному количеству вероятных в будущем изменений. Поскольку системы стали более сложными, «проблема проектирования находится вне алгоритмов и структур данных: проектирование и определение общей структуры системы является проблемой иного типа»
Кроме того, часто имеется существующая система, которая исполняет некоторые из функций проектируемой системы. Определение того, что делает эта система, при минимуме документации или вообще без нее, и решение вопроса о том, какую часть унаследованного кода разработчики могли бы использовать повторно, добавляет разработке сложности.
Мы нуждаемся в архитектуре для того, чтобы:
-
понять систему;
-
организовать разработку;
-
способствовать повторному использованию кода;
-
развивать систему в дальнейшем.
-
Варианты использования и архитектура
Уточним, как происходит этот процесс, рассмотрев сначала, что оказывает влияние на архитектуру (рис. 4.1), а затем — какие факторы влияют на варианты использования.
Варианты использования — это направляющие для архитектуры. В конце концов, мы хотим иметь архитектуру, которая является подходящей для осуществления наших вариантов использования. На ранних итерациях мы выбираем несколько вариантов использования, которые, как мы полагаем, позволят нам наилучшим образом разработать архитектуру. Эти важные для создания архитектуры варианты использования будут включать те, которые необходимы клиентам в текущем выпуске и, возможно, в последующих выпусках.
Однако на архитектуру будут влиять не только важные для архитектуры варианты использования, но и другие факторы:
-
Системное программное обеспечение, которым мы хотим пользоваться для построения системы (например, операционной системой или СУБД).
-
Программное обеспечение среднего уровня, которое мы хотим использовать. Например, мы должны выбрать брокер объектных запросов, предоставляющий механизм прозрачного маршалинга и доставки сообщений распределенным объектам в гетерогенных средах или платформо-независимый каркас для создания пользовательского графического интерфейса.
-
Унаследованные системы, которые войдут в нашу систему. Включая унаследованную систему, например существующую банковскую систему, в наш программный комплекс, мы можем повторно использовать множество существующих функций, но будем вынуждены приспосабливать нашу архитектуру к старому продукту.
-
Стандарты и правила компании, которые мы должны соблюдать. Например, мы можем быть вынуждены использовать язык определения интерфейсов IDL , созданный OMG для определения интерфейсов к классам или стандарт телекоммуникаций TMN — для определения объектов системы.
-
Общие нефункциональные требования (то есть не привязанные к конкретному варианту использования), типа требований к доступности, времени восстановления или потребления памяти.
-
Требования к распределению, определяющие, как система распределяется по компьютерам, например согласно архитектуре клиент/сервер.
Разработка архитектуры происходит на итерациях фазы проектирования. Упрощенный, немного наивный подход — мысленная модель — осуществляется следующим образом. Мы начинаем с определения типа архитектуры, например послойной архитектуры После этого в течение нескольких билдов первой итерации мы создаем архитектуру.
В первом билде мы работаем с частями общего уровня приложений
которые являются общими для предметной области и не специфичны для системы, которую мы собираемся разрабатывать. Имеется в виду, что мы выбираем системное программное обеспечение, средний уровень, наследуемые системы, используемые стандарты и правила. Мы решаем, какие узлы будут присутствовать в нашей модели развертывания и как они должны взаимодействовать друг с другом. Мы решаем, как удовлетворить общие нефункциональные требования, например требования по доступности. На этом первом проходе достаточно будет добиться общего понимания приложения.
Во втором билде мы работаем с архитектурой специфического уровня приложения. Мы выбираем комплект архитектурно значимых вариантов использования, определяем требования, анализируем их, проводим проектирование, реализуем и тестируем их. Результатом будут новые подсистемы, реализованные в виде компонентов. Они создаются для поддержки выбранных нами вариантов использования. Кроме того, теперь, рассмотрев систему в понятиях вариантов использования, мы можем захотеть внести некоторые изменения в архитектурно значимые компоненты, выбранные во время первого билда. Для реализации вариантов использования создаются новые компоненты и изменяются старые. Таким образом мы адаптируем архитектуру для лучшего удовлетворения вариантам использования. Затем мы делаем следующий билд, затем еще и еще, пока не закончим итерацию. Когда фаза проектирования заканчивается, архитектура должна быть стабилизирована.
После того, как мы создали устойчивую архитектуру, мы можем вводить в систему полный список функциональных возможностей, реализуя в ходе фазы построения оставшиеся варианты использования. Варианты использования, реализуемые в течение фазы построения, обычно разрабатываются с использованием в качестве исходных данных требований пользователей и клиентов (рис. 4.2). Варианты использования также находятся под влиянием архитектуры, выбранной на фазе проектирования.
Чтобы лучше определять новые варианты использования, мы применяем наше знание архитектуры. Когда мы оцениваем ценность каждого предложенного варианта использования и затраты на него, мы делаем это применительно к существующей архитектуре. Некоторые варианты использования будут легко осуществимы, в то время как осуществить другие будет затруднительно.