Введение в архитектуру программного обеспечения

ВВЕДЕНИЕ 
В АРХИТЕКТУРУ 
ПРОГРАММНОГО 
ОБЕСПЕЧЕНИЯ

Л.Г. ГАГАРИНА
А.Р. ФЕДОРОВ
П.А. ФЕДОРОВ

Рекомендовано 
Межрегиональным учебно-методическим советом 
профессионального образования в качестве учебного пособия 
для учебных заведений, реализующих программу 
среднего профессионального образования 
по укрупненной группе специальностей 
09.02.00 «Информатика и вычислительная техника» 
(протокол № 12 от 24.06.2019)

Москва
ИД «ФОРУМ» — ИНФРА-М
2020

УЧЕБНОЕ ПОСОБИЕ

УДК 004(075.32)
ББК 32.973-018я723
 
Г12

Гагарина Л.Г.
Г12 
 
Введение в архитектуру программного обеспечения : учебное 
пособие / Л.Г. Гагарина, А.Р. Федоров, П.А. Федоров. — Москва : 
ИД «ФОРУМ» : ИНФРА-М, 2020. — 320 с. — (Среднее профессиональное образование). 

ISBN 978-5-8199-0903-4 (ИД «ФОРУМ»)
ISBN 978-5-16-015696-5 (ИНФРА-М)
Рассмотрены первостепенные задачи, возникающие при разработке 
крупных проектов программного обеспечения, в которых принимают участие сотни разработчиков. Сложность программного обеспечения — это его 
существенное и неслучайное свойство. На технологию разработки влияют 
различные факторы, включающие в том числе проблемы проектирования, воздействие экономики, влияние политики, недостаток воображения. 
Уменьшение рисков снижения успешности или даже провала крупных 
разработок возможно при использовании архитектурного подхода к проектированию программного обеспечения, основанного на определении 
глобальных ограничений, накладываемых на проектирование системы, 
таких как выбор парадигмы программирования, архитектурных стилей, 
стандартов разработки.
Строгий стиль изложения сопровождается доступными для понимания 
пояснениями и многочисленными примерами, необходимыми для глубокого усвоения материала.
Адресовано студентам учреждений среднего профессионального образования, обучающимся по специальности 09.02.07 «Информационные системы и программирование».

УДК 004(075.32)
ББК 32.973-018я723

Р е ц е н з е н т:
Бондаревский А.С. — доктор технических наук, профессор

ISBN 978-5-8199-0903-4 (ИД «ФОРУМ»)
ISBN 978-5-16-015696-5 (ИНФРА-М)

© Гагарина Л.Г., Федоров А.Р., 
Федоров П.А., 2020
© ИД «ФОРУМ», 2020

Введение

Cовременная жизнь немыслима без компьютеров — это любая бытовая техника, автомобили, общественный транспорт, телекоммуникационные и корпоративные системы. Продолжать можно практически бесконечно. Разумеется, все это управляется программами более
или менее сложными. Постоянно возрастает разнообразие и сложность систем, использующих программное обеспечение (ПО), соответственно возрастают финансовые затраты на ПО как на этапе исследований, так и на этапе разработок.
Институт программной инженерии университета Карнеги—Меллон (Software Engineering Institute, SEI) — общепризнанный законодатель в предметной области «Исследований и разработок систем, интенсивно использующих ПО» к классу таких систем относит «системы, в которых ПО представляет существенный сегмент по следующим
позициям: функциональность системы, ее стоимость, риски в процессе разработки, время разработки» [1]. В таких системах компоненты
ПО взаимодействуют с другими ПОкомпонентами, компонентами и
подсистемами другой природы, датчиками, приборами и людьми, вовлеченными в процессы использования ПО.
Для разработок систем, интенсивно использующих ПО, типичны
крупномасштабные проекты — десятки или сотни разработчиков, месяцы или годы разработки, сотни тысяч или десятки миллионов долларов. К сожалению, разработки таких систем часто приводят к результатам, которые не соответствуют запланированным ожиданиям.
Значительное число разработок либо прекращается, либо превышает
запланированное время и/или средства, либо завершается в более
бедной версии. Степень успешности, выраженная в процентах числа
проектов, завершившихся в соответствии с исходными замыслами и
планами, невысока и, по некоторым оценкам, не превышает 35 % [2].

К числу негативных факторов, приводящих к снижению успешности и даже провалам крупных разработок, относятся:
• нереальные проектные цели;
• ошибочные оценки необходимых ресурсов;
• неадекватная система требований;
• слабое документирование текущего состояния проекта;
• отсутствие или слабое управление рисками;
• слабое коммуникативное взаимодействие лиц, заинтересованных в проекте;
• использование незрелых технологий;
• неспособность коллектива справиться со сложностью проекта;
• небрежности в разработке;
• слабое управление проектом;
• отсутствие достаточной благоразумности лиц, заинтересованных в проекте;
• коммерческое давление на разработчиков и менеджеров проекта.
Для предостережения разработчиков ПО созданы каталоги классических ошибок. Один из таких каталогов представлен в [3], где типовые ошибки распределены по группам «разработчик», «процесс»,
«продукт» и «технология». Вот некоторые из них: увеличение числа
исполнителей для завершения проекта, нереалистичные ожидания,
принятие желаемого за действительное, исключение важных задач из
процесса проверок, переключение на другие инструменты по ходу
проектирования.
Сложность ПО — это его существенное и не случайное свойство.
На технологию разработки систем оказывают влияние законы построения ПО, изменение алгоритмов в процессе разработки ПО,
трудности распределения структур и функций, проблемы проектирования, проблемы функциональности, важность организации процесса разработки ПО, воздействие экономики, влияние политики, недостаток воображения.
Уже перечисленного вполне достаточно для того, чтобы понять
необходимость применения любых средств, позволяющих снизить
сложность как конкретного ПО, так и процесса его разработки.
Важным концептуальным для методологии программной инженерии моментом стало введение понятия «архитектура» в его применении к ПО и системам, базирующимся на ПО. Началом использования современного значения этого понятия принято считать 1992 г. —

4
Введение

работа Д. Перри и А. Вульфа [4]. Дальнейшие исследования в системной и программной инженерии позволили выввести взаимосвязанную совокупность архитектур [2, 5, 6]:
• программного обеспечения;
• аппаратного обеспечения в базисе основных единиц компьютерной и телекоммуникационной техники;
• информационного обеспечения;
• организационного обеспечения, раскрывающего связность организационных структур (в том числе на уровне персонифицированных ролей и ответственности) с бизнеспроцессами;
• предприятия с позиций бизнеса, в общем случае выходящего за
рамки компании.
Важные результаты, полученные в последние годы:
• создана предметная область «Архитектура ПО», задачи которой
для разработки ПО носят принципиальный характер;
• разработан и широко используется на практике ряд международных стандартов, в которых переосмыслен и обобщен опыт
разработок ПО с различных позиций (жизненный цикл, работа
с требованиями, архитектура, качество, организационнопрофессиональная зрелость коллективов разработчиков и др.);
• созданы технологии и инструментальные средства, аналогов которых в предшествующей инженерной практике не было (например, мастерметодология Rational Unified Process (RUP)
[7, 8], инструментальные средства программирования для корпоративных сетей, в том числе и для WEBпрограммирования);
• создан и подтвердил на практике свою исключительную полезность унифицированный язык моделирования UML [9].

Введение
5

Глава 1
АРХИТЕКТУРА КАК ФОРМА
КОНЦЕПТУАЛЬНОГО СУЩЕСТВОВАНИЯ ПО

1.1. Определения архитектуры ПО
и ее значимость

Существует множество определений понятия «архитектура ПО».
Одного и безоговорочно принятого определения архитектуры не существует. Наиболее богатая коллекция вариантов употреблений этого
термина представлена на сайте SEI [1], где каждому, кто считает, что
он сформулировал это понятие более точно, предоставлена возможность включить его в общую коллекцию.
Мы будем придерживаться следуюшего определения.

Архитектура программного обеспечения (software architecture) — это
структура программы или вычислительной системы, которая включает
программные компоненты (элементы), видимые снаружи свойства этих
компонентов, а также отношения (взаимодействия) между ними. Архитектура затрагивает не только структуру и поведение, но также использование, функциональность, и другие аспекты. Этот термин также
относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между стейкхолдерами (stakeholders — лица, заинтересованные
в проекте), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет
использовать компоненты этого дизайна и шаблоны повторно в других
проектах.

Причем архитектура программного обеспечения это не блочная
диаграмма, весьма приблизительно отражающая функциональную декомпозицию системы. Программная архитектура — многогранный
подход, гарантирующий, что программное обеспечение будет отвечать
своему предназначению.
Основополагающей идеей дисциплины программной архитектуры является идея снижения сложности системы путем абстракции и
разграничения полномочий.
Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией
функциональных требований.
Архитектура ПО, которую также можно представить себе в виде
разработки стратегии — это деятельность, связанная с определением
глобальных ограничений, накладываемых на проектирование системы, таких как выбор парадигмы программирования, архитектурных
стилей, стандартов разработки ПО, основанных на использовании
компонентов, принципов проектирования, и ограничения, накладываемые государственным законодательством. Детальное проектирование, т. е. разработка тактики, — это деятельность, связанная с определением локальных ограничений проекта, таких как шаблоны проектирования, архитектурные модели, идиомы программирования и
рефакторинга [9, 10, 11, 12].
В работе [13] предложено следующее толкование ряда позиций
определения архитектуры.
Архитектура в любой версии определяет структуру. Разумеется, архитектура не сводится только к структурам (деление на части, элементы, интерфейсы, связи, взаимодействие), но структурный аспект в ее
содержании и его материализации является наиболее существенным.
Архитектура определяет поведение. Архитектура определяет не
только структуры системы через элементы и связи, но также и взаимодействие элементов структур, осуществляемое во времени. Для выражения динамики процессов в архитектурных описаниях используют различные средства, например «диаграммы последовательностей»
на языке UML.
Архитектура фокусирует свои интересы на существенных элементах
структуры и поведения. При построении архитектуры разработчики
абстрагируются до самого существенного ввлияющего на жизнеспособность проекта как целого.

1.1. Определения архитектуры ПО и ее значимость
7

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

8
Глава 1. Архитектура как форма концептуального существования ПО

1.2. Место архитектурных решений

Содержание определений архитектуры явно и неявно указывает
на место архитектурных решений и их роль в разработке ПО.
В современной практике разработки ПО широко используется
спиральноитеративная модель жизненного цикла, что приводит к
необходимости возврата к вопросам разработки архитектуры с каждым циклом спирали (рис. 1).

В процессе разработки ПО границы между этапами жизненного
цикла и итерациями в рамках одного и того же этапа «размыты». Это
особенно типично для этапов анализа требований (результатом которого является система требований — СТ) и разработки архитектуры
(результатом которого является архитектурное описание — АО). Каждый из этапов «анализа» и «архитектуры» приводит к определенной
форме существования ПО в рамках его жизненного цикла, что показано на рис. 2.
На рисунке показано, что формы существования ПО на ранних
этапах разработки являются концептуальными, т. е. представляют собой связную совокупность текстовых (в том числе табличных) документов, графических моделей и диаграмм (часто использующих для
своего представления язык UML) [14].
Повторимся — не существует четкого разграничения понятия архитектурного программирования и реализации ПО. Часть перечисленных пунктов может быть и не отнесена к категории архитектура.
Так же как и некоторые формулировки принципов модульного программирования и ООП могут быть отнесены к архитектурным реше1.2. Место архитектурных решений
9

Рис. 1. Спиралевидный процесс разработки

ниям. Но самое главное требование к архитектуре — расширяемость—
масштабируемость. Если ее нет — то это не архитектурное решение.
Например, стиль приложения клиент—сервер считается архитектурным стилем (стратегическим дизайном), потому что программа,
которая построена на этом принципе, может быть расширена в программу, которая не является клиентсервером, например, путем добавления peertopeer узлов.
Архитектура является проектированием (дизайном), но не всякий
дизайн является архитектурным дизайном. На практике архитектор
определяет грань между архитектурой программного обеспечения
(архитектурным дизайном) и детальным дизайном (неархитектурным
проектированием).
Являясь в настоящий момент своего развития дисциплиной без
четких правил, проектирование архитектуры ПО все еще является
смесью науки, искусства и «магии».
Аспект «искусства—магии» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии.
То, как сформулированы ключевые цели системы, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющие, как будет вести
себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость,
надежность, пригодность к сервисному обслуживанию, доступность,
безопасность, удобство использования и пр.
С точки зрения пользователя программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например заинтересованного

10
Глава 1. Архитектура как форма концептуального существования ПО

Рис. 2. Архитектура, как форма концептуального существования ПО

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

1.3. Роль архитектурных решений

Построение и использование архитектурного подхода в разработке ПО может быть обобщенно представлено как последовательность
обобщенных действий: понимание + анализ + коммуникация + конструирование [2].
Перечислим положительные факторы, получаемые от построения
и использования архитектуры ПО. Архитектура:
• вносит вклад в формирование системы требований к ПО;
• показывает совокупность ранних проектных решений;
• описывает организационную структуру ПО;
• является общим базисом для линеек программных продуктов;
• позволяет учитывать, согласовывать и предсказывать характеристики качества, в том числе и по результатам ее исследования;
• дает информацию о распределении работ и их календарных
планах;
• дает возможность для более точной оценки стоимости и расписания работ;
• снижает риски;
• является первой формой существования ПО, которая может
быть проверена (испытана) как целое;
• предоставляет возможность для переноса или повторного использования стилей и архитектурных каркасов;
• приносит выгоду в ограничении «словаря» альтернатив проекта
или его частей;
• помогает в эволюционном прототипировании;
• оформляет концептуальную целостность ПО и процесса его
разработки;

1.3. Роль архитектурных решений
11