Архитектуры программных систем

4. АРХИТЕКТУРЫ  ПРОГРАММНЫХ СИСТЕМ

4.1. Планирование архитектуры

Современные методы разработки программного обеспечения  предпола-

гают обратную связь между всеми действующими лицами, от проектировщи-

ка до аналитика. Все эти лица являются участниками процесса создания ар-

хитектуры программной системы. Под архитектурой системы будем пони-

мать  структуру компонентов программной  системы, взаимосвязи, а также

принципы  и нормы их проектирования и развития во времени. Прежде чем

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

миться с понятием архитектурно-экономического цикла (АЭЦ).

4.1.1. Архитектурно-экономический  цикл

Взаимоотношения между производственными задачами, требования к

продукту, опыт архитектора, архитектуры и  созданные системы образуют

цикл  с цепями обратной связи. Упомянутые цепи обратной связи изображены

на рис. 4.1. Частично обратная связь поступает от самой архитектуры, час-

тично – от построенной на ее основе системы.

Рис. 4.1. Архитектурно-экономический цикл

Цикл  выглядит следующим образом.

1. Архитектура  влияет на структуру компании-разработчика. Архитек-

тура  обусловливает структуру системы; в частности (в этом мы сможем убе-

диться), она устанавливает набор блоков программного обеспечения, которое

надлежит  реализовать (или обеспечить их наличие  другим путем), а затем

интегрировать в рамках системы. Эти блоки составляют основу разработки

структуры проекта. Группы разработчиков укомплектовываются именно по

блокам; операции в рамках процессов разработки, тестирования и интегра-

ции также выполняются в отношении блоков. Согласно графикам и бюдже-

там, ресурсы  выделяются частями в расчете  на отдельные блоки. Если ком-

пания наработала опыт конструирования семейств сходных систем, она будет

вкладывать  средства в повышение профессионального  уровня участников

сформированных  по блокам групп разработчиков. Следовательно, группы

встраиваются  в структуру организации. Такой  представляется обратная связь

от архитектуры  к компании-разработчику.

2. Архитектура  способна оказывать воздействие  на задачи компании-

разработчика. Сконструированная __________на ее основе успешная система предостав-

ляет компании возможность укрепиться в данном сегменте рынка. Такая ар-

хитектура предусматривает дальнейшее эффективное производство и разме-

щение сходных систем, вследствие чего компания может откорректировать

свои  задачи и, воспользовавшись новым преимуществом, занять рыночную

нишу. Так  выглядит обратная связь от системы  к компании-разработчику и

конструируемым  ею системам.

3. Архитектура  может оказывать воздействие  на требования, выдвигае-

мые заказчиком относительно следующей системы, – ее (если она основана

на той  же архитектуре, что и предыдущая) он может получить в более надеж

ном варианте, быстрее и экономичнее, чем в  том случае, если бы она конст-

руировалась с чистого листа. Возможно, заказчик откажется от некоторых

требований  в пользу повышения экономичности. Готовые программные про-

дукты несколько изменили требования, предъявляемые заказчиками, – не

предназначенные для удовлетворения индивидуальных потребностей, они

недороги и отличаются высоким качеством. На заказчиков, не слишком гиб-

ких по части своих требований, аналогичное воздействие оказывают линейки

продуктов.

4. Процесс  конструирования систем пополняет  опыт архитектора, ко-

торый он может применить при работе над последующими архитектурами, и,

соответственно, расширяет базу опыта компании. Успех  системы, построен-

ной на основе инструментальных магистралей, .NET или инкапсулированных

конечных  автоматов, стимулирует построение аналогичных систем в даль-

нейшем. С другой стороны, неудачные варианты архитектуры редко исполь-

зуются повторно.

5. Иногда  оказать сильное воздействие  и даже внести изменения в

культуру  программной инженерии (техническую  базу, в рамках которой обу-

чаются  и работают конструкторы) способны отдельные системы. Такой эффект на индустрию в 1960-х и начале 1970-х  гг. оказали первые реляционные

базы  данных, генераторы компиляторов и  табличные операционные системы;

в 1980-х  – первые электронные таблицы  и системы управления окнами.

В 1990-х  гг. в качестве такого рода катализатора выступила Всемирная

паутина. Подобные инновации всегда находят  отражение в последующих

системах.

Из этих и некоторых других механизмов обратной связи и образуется

архитектурно-экономический  цикл. На рис. 4.1 изображены факторы влияния

культуры  и экономики компании-разработчика на программную архитектуру.

В свою очередь архитектура оказывается  основным определяющим фактором

при задании  свойств разрабатываемой системы  или систем.

4.1.2. Программный процесс  и архитектурно-экономический  цикл

Программным процессом (software process) называются действия по

организации, нормированию и управлению разработкой  программного обес-

печения. Ниже приведен перечень операций, направленных на создание про-

граммной архитектуры, ее применение для реализации проектного решения,

а впоследствии – на реализацию или управление развитием целевой системы

или приложения:

создание  экономической модели системы;

выявление требований;

создание  новой или выбор существующей архитектуры;

документирование  и распространение сведений об архитектуре;

анализ  или оценка архитектуры;

реализация  системы на основе архитектуры;

проверка  соответствия реализации архитектуре.

4.1.2.1. Этапы разработки архитектуры

Как следует  из структуры АЭЦ, между различными этапами разработки

архитектуры существуют развернутые отношения  обратной связи

Создание  экономической модели системы. Создание экономической

модели  не ограничивается оценкой потребности  в системе на рынке. Этот

этап  исполняет существенную роль в контексте  создания и сужения требова-

ний. Сколько должен стоить продукт? Каков целевой сегмент рынка? На-

сколько быстро продукт должен выйти на рынок? Должен ли он взаимодей-

ствовать с другими системами? Есть ли какие-нибудь системные ограниче-

ния, в рамках которых он должен существовать?

Все эти  вопросы решаются с привлечением архитектора. Одного его,

конечно, недостаточно, однако если при создании экономической модели

консультации  с архитектором не проводились, то возможность  достижения

коммерческих  задач становится проблематичной.

Выявление требований. Способов узнать, чего же, наконец, хотят за-

интересованные  лица, множество. В частности, в рамках объектно-ориен-

тированного анализа для фиксации требований используются сценарии, или

элементы  Use Case. Для системы с повышенными требованиями к безопасно-

сти применяются более строгие методики – например, модели конечных ав-

томатов и языки формальных спецификаций.

Применительно к конструируемой системе необходимо принять цен-

тральное, основополагающее решение – насколько  в ней будут отражены

другие, уже сконструированные системы. Поскольку в сегодняшних услови-

ях найти систему, не имеющую сходств с другими системами, весьма непро-

сто, методики выявления требований предполагают знание характеристик

предшествующих  систем.

Еще один способ выявления требований подразумевает  моделирование.

Опытные системы помогают моделировать нужное поведение, проектировать

пользовательские  интерфейсы и проводить анализ потребления  ресурсов. Та-

ким образом, в глазах заинтересованных лиц система становится «реальной»,

а процесс  принятия решений по проектированию системы и ее пользователь-

ского интерфейса значительно ускоряется.

Вне зависимости  от методики выявления требований, желаемые атри-

буты  качества конструируемой системы обусловливают  ее конечный вид.

Для обеспечения  отдельных атрибутов качества архитекторами  уже давно

применяются те или иные тактики. Архитектурные решения компромиссны,

однако  при специфицировании требований не все эти компромиссы очевид-

ны. Со всей ясностью они проявляются только после создания архитектуры;

тогда же принимаются решения относительно сортировки требований в соот-

ветствии с приоритетами.

Создание  или выбор архитектуры. Фредерик Брукс (Fred Brooks)

в своей  знаменитой книге «Мифический человеко-месяц» красноречиво и

убедительно доказывает, что основным условием стабильного проектирова-

ния системы является соблюдение концептуальной целостности, а она может

проявиться  лишь в узком кругу людей, совместно  работающих над проекти-