1 Основы проектирования программных систем

Рис. 6-2- Информационные связи процесса проектирования

Архитектурное нроектирование обеснечивает понимание правильной органи­зации системы и создает структуру под эту правильную организацию. Оно напря­мик связывает весь этап проектирования с детальными требованиями, поскольку архитектура выделяет основные структурные компоненты системы и формирует отношения между ними.
Между созданием детальных требований и архитектурным проектированием имеется существенное нерекрытие. В идеале в требованиях не должно быть ин­формации о структуре системы. На самом же деле это справедливо только для малых систем. Архитектурное разделение системы на части просто необходимо для структуризации и организации спецификации требований. Поэтому перед созданием детальных требований формируется абстрактная архитектура системы, с подсистемами которой ассоциируются целые группы функций и характеристик. Эта же архитектура используется для обсуждения требований и характеристик системы с заинтересованными лицами.
Многие авторы отмечают разностороннее и решающее воздействие архитектуры на качество программной системы [40, 88, 94]:

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

Различным требованиям к интегральным характеристикам системы должны соответствовать разные варианты архитектуры. Обсудим эти варианты.
Если главным требованием является производительность системы, следует снроектировать архитектуру, которая локализует критические операции в пределах небольшого количества подсистем с минимальным числом взаимодействий между ними. Эти подсистемы следует развернуть на одном и том же компьютере, а не рас­пределять по сети. Для сокращения внешних коммуникаций нодсистемы должны быть крунными, с большой степенью автономности.
Для обеспечения максимальной защищенности архитектура должна быть много­уровневой, причем самые ценные подсистемы следует размещать на внутренних уровнях, с высокой степенью защиты.
При ориентации на максимальную безопасность поддержку безопасности нужно сосредоточить в одной нодсистеме (или малом числе нодсистем). Это уменьшит стоимость проектирования и позволит применить эффективный механизм про­верки надежности. Такой механизм обеснечит максимальную сохранность данных при отказе в системе.
Для создания устойчивости к отказам (обеспечения бесперебойности работы) в архитектуру вводятся избыточные (резервные) нодсистемы. Их наличие по­зволяет выполнять замену отказавших элементов без остановки системы.
Наконец, удобство сопровождения повышается при проектировании архитек­туры из малых подсистем, которые легче проверять и обновлять. Для облегчения диагностики ошибок желателен отказ от глобальных структур данных. Заметим, что нри этом возникает конфликт с архитектурой, нацеленной на максимальную производительность. Там нужны большие подсистемы, здесь — малые. Приходится идти на какой-то компромисс.
Поиск компромиссного решения — типичная задача архитектурного проектиро­вания, носкольку, как нравило, требуется максимизация многих параметров системы.
Архитектура системы часто моделируется с помощью простых блочных диаграмм. Каждый блок в диаграмме представляет нодсистему (компонент). Блоки внутри блоков означают, что компонент разбивается на субкомпоненты. Стрелки показы­вают нередачу данных и управляющих сигналов между компонентами. Конечно, блочные диаграммы — скудное средство. За кадром остаются такие важные вопросы,

как типы взаимодействий между компонентами, многочисленные характеристики компонентов-подсистем. Фактически блочная диаграмма отражает только структуру системы. Зато она нроста и наглядна. Многие считают, что это «святая простота»:

• 
  Она нолезна для обсуждения системы с заинтересованными лицами и для пла­нирования проекта, потому что не обременена деталями.
  
• 
  Не специалист, но заинтересованное лицо сможет понять главные идеи органи­зации системы, не вдаваясь в детали.
  
• 
  Менеджер видит ключевые компоненты, которые должны быть разработаны, и начинает понимать, каких сотрудников надо привлечь к разработке.
  

Скудность блочной диаграммы можно компенсировать документированием архи­тектуры. За счет документирования формируется подробное архитектурное описа­ние, которое ноясняет различные компоненты системы, их интерфейсы, соединения и облегчает понимание и развитие системы. Правда, на практике иногда полезность архитектурных документов недооценивают, то есть игнорируют эту работу. Отметим, что в гибких нроцессах разработки ранняя стадия работ нацелена на создание мини­мальной версии архитектуры системы, которая в дальнейших итерациях изменяется и развивается до полномасштабного варианта. Как нравило, пошаговое изменение архитектуры нроблематично и очень часто заканчивается провалом.
Во время архитектурного проектирования системные архитекторы должны принимать такие решения, которые глубоко затрагивают систему и процесс ее разработки. Основываясь на своих знаниях и опыте, они решают широкий спектр задач. Все эти задачи группируются вокруг трех тинов базисной деятельности.
Базисная деятельность архитектурного проектирования включает:

1. 
   Структурирование системы². Система структурируется на несколько нодси- стем, где нод подсистемой нонимается независимый программный комнонент. Определяются взаимодействия подсистем.
   
2. 
   Моделирование управления. Формируется стратегия управления частями системы.
   
3. 
   Декомпозиция подсистем на модули. Каждая нодсистема разбивается на модули.
   

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