Главная | Обратная связь | Поможем написать вашу работу!

Архитектурное проектирование

Цели

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

q понимать, для чего необходимо архитектурное проектирование ПО;

q знать различные модели, используемые при документировании системной архитектуры;

q иметь представление о разных типах архитектур ПО: структурной модели системы, модели системной декомпозиции по управлению и модели модульной декомпозиции;

q знать модели проблемно-зависимых архитектур, которые используются как основа для архитектур специализированных программных систем и как эталон при сравнении различных архитектур.

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

В разделе 3.4 рассматривалась общая структура процесса проектирования. На рис. 3.9 была представлена модель процесса проектирования, первым этапом которого является архитектурное проектирование, служащее соединяющим звеном между процессом проектирования и процессом разработки требований к создаваемой системе. В идеале в спецификации требований не должно быть информации о структуре системы. В действительности же это справедливо только для небольших систем. Архитектурная декомпозиция системы необходима для структуризации и организации системной спецификации. Хорошим примером тому может служить изображенная на рис. 2.3 система управления воздушными полетами. Модель системной архитектуры часто является отправной точкой для создания спецификации различных частей системы. В процессе архитектурного проектирования разрабатывается базовая структура системы, т.е. определяются основные компоненты системы и взаимодействия между ними.

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

1. Структурирование системы. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами. Этот этап рассматривается в разделе 10.1.

2. Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы. Этот этап рассматривается в разделе 10.2.

3. Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типы их взаимосвязей. Этот этап рассматривается в разделе 10.3.

Как правило, эти этапы перемежаются и накладываются друг на друга. Этапы повторяются для все более детальной проработки архитектуры до тех пор, пока архитектурный проект не будет удовлетворять системным требованиям.

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

1. Подсистема – это система (т.е. удовлетворяет "классическому" определению "система"), операции (методы) которой не зависят от сервисов, предоставляемых другими подсистемами. Подсистемы состоят из модулей и имеют определенные интерфейсы, с помощью которых взаимодействуют с другими подсистемами.

2. Модуль – это обычно компонент системы, который предоставляет один или несколько сервисов для других модулей. Модуль может использовать сервисы, поддерживаемые другими модулями. Как правило, модуль никогда не рассматривается как независимая система. Модули обычно состоят из ряда других, более простых компонентов.

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

1. Статическая структурная модель, в которой представлены подсистемы или компоненты, разрабатываемые в дальнейшем независимо.

2. Динамическая модель процессов, в которой представлена организация процессов во время работы системы.

3. Интерфейсная модель, которая определяет сервисы, предоставляемые каждой подсистемой через общий интерфейс.

4. Модели отношений, в которых показаны взаимоотношения между частями системы, например поток данных между подсистемами.

Ряд исследователей при описании архитектуры систем предлагают использовать специальные языки описания архитектур. В книге [29] рассматриваются основные свойства этих языков. В них основными архитектурными элементами являются компоненты и коннекторы (объединяющие звенья); эти языки также предлагают принципы и правила построения архитектур. Однако, как и другие специализированные языки, они имеют один недостаток, а именно: все они понятны только освоившим их специалистам и почти не используются на практике. Фактически использование языков описания архитектур только усложняет анализ систем. Поэтому я считаю, что для описания архитектур лучше использовать неформальные модели и системы нотации, подобные предлагаемой, например унифицированный язык моделирования UML.

Архитектура системы может строиться в соответствии с определенной архитектурной моделью [126]. Очень важно знать эти модели, их недостатки, преимущества и возможности применения. В этой главе рассматриваются структурные модели, модели управления и декомпозиции.

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

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

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

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

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

4. Надежность. В этом случае следует разработать архитектуру с включением избыточных компонентов, чтобы можно было заменять и обновлять их, не прерывая работу системы. Архитектуры отказоустойчивых систем с высокой работоспособностью рассматриваются в главе 18.

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

Очевидно, что некоторые из перечисленных архитектур противоречат друг другу. Например, для того чтобы повысить производительность, необходимо использовать крупномодульные компоненты, в то же время сопровождение системы намного упрощается, если она состоит из мелких структурных компонентов. Если необходимо учесть оба требования, следует искать компромиссное решение. Ранее уже было сказано, что один из способов решения подобных проблем состоит в применении различных архитектурных моделей для разных частей системы.

⇐ Предыдущая 62 63 64 65 666768 69 70 71 Следующая ⇒