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

ВВЕДЕНИЕ 

В АРХИТЕКТУРУ 
ПРОГРАММНОГО 

ОБЕСПЕЧЕНИЯ

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

Рекомендовано 

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

профессионального образования в качестве учебного пособия 

для учебных заведений, реализующих программу 

среднего профессионального образования 

по укрупненной группе специальностей 

09.02.00 «Информатика и вычислительная техника» 

(протокол № 12 от 24.06.2019)

Москва

ИД «ФОРУМ» — ИНФРА-М

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

-
-

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

Гагарина Л.Г.

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

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

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

Рассмотрены первостепенные задачи, возникающие при разработке 

крупных проектов программного обеспечения, в которых принимают учас-
тие сотни разработчиков. Сложность программного обеспечения — это его 
существенное и неслучайное свойство. На технологию разработки влияют 
различные факторы, включающие в том числе проблемы проектирова-
ния, воздействие экономики, влияние политики, недостаток воображения. 
Уменьшение рисков снижения успешности или даже провала крупных 
разработок возможно при использовании архитектурного подхода к про-
ектированию программного обеспечения, основанного на определении 
глобальных ограничений, накладываемых на проектирование системы, 
таких как выбор парадигмы программирования, архитектурных стилей, 
стандартов разработки.

Строгий стиль изложения сопровождается доступными для понимания 

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

Адресовано студентам учреждений среднего профессионального обра-

зования, обучающимся по специальности 09.02.07 «Информационные сис-
темы и программирование».

УДК 004(075.32)

ББК 32.973-018я723

Р е ц е н з е н т:

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

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

© Гагарина Л.Г., Федоров А.Р., 

Федоров П.А., 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. Архитектура, как форма концептуального существования ПО