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

-¬¡ ©¡¡
«¬ª°¡--¤ª©œ§¸©ª¡
ª¬œ£ªžœ©¤¡
-ÁÌÄÛ
ÊÍÉʾ¼É¼
¾

¿ÊÀÏ
Л.Г. ГАГАРИНА 
А.Р. ФЕДОРОВ 
П.А. ФЕДОРОВ
ПРОЕКТИРОВАНИЕ 
И АРХИТЕКТУРА 
ПРОГРАММНЫХ СИСТЕМ
УЧЕБНОЕ ПОСОБИЕ
2-е издание, исправленное и дополненное
Москва
ИНФРА-М
2025

УДК 004(075.32)
ББК 32.973-018я723
 
Г12
Р е ц е н з е н т :
Портнов Е.М., доктор технических наук, профессор
Гагарина Л.Г.
Г12 
 
Проектирование и архитектура программных систем : учебное пособие / Л.Г. Гагарина, А.Р. Федоров, П.А. Федоров. — 2-е изд., испр. 
и доп. — Москва : ИНФРА-М, 2025. — 334 с. — (Среднее профессиональное образование). 
ISBN 978-5-16-020565-6 (print)
ISBN 978-5-16-113217-3 (online)
В учебном пособии рассмотрены первостепенные задачи, возникающие 
при разработке крупных проектов программных систем. Представлены 
принципы архитектуры программного обеспечения, основные виды, характеристики, преимущества, типы архитектурных стилей и архитектурные паттерны. Лаконичный стиль изложения сопровождается доступными 
для понимания пояснениями и примерами, необходимыми для глубокого 
усвоения материала.
Соответствует требованиям федеральных государственных образовательных стандартов среднего профессионального образования последнего 
поколения.
Для студентов, обучающихся по укрупненной группе специальностей 
«Информатика и вычислительная техника».
Книга может быть использована для самообразования.
УДК 004(075.32)
ББК 32.973-018я723
ISBN 978-5-16-020565-6 (print)
ISBN 978-5-16-113217-3 (online)
© Гагарина Л.Г., Федоров А.Р., 
Федоров П.А., 2018
© Гагарина Л.Г., Федоров А.Р., 
Федоров П.А., 2024, 
с изменениями

Введение
Прошло более полувека с момента возникновения первых языков 
программирования. За этот период появились понятия модульности, 
операционной системы, жизненного цикла программного обеспечения (ПО) и ряд языков программирования в соответствии с вызовами времени. Сменились парадигмы разработки ПО с централизованной на децентрализованную, появились программные системы 
(ПС), в начале 1990-х гг. значительно выросла их сложность, соответственно нарастало и количество проблем, связанных с ПС. Результатом поиска путей снижения сложности ПС путем абстракции 
и разграничения полномочий стала концепция архитектуры программного обеспечения, в рамках которой систематизированы и упорядочены основные аспекты создания ПС. Однако до сих пор каноническое определение программной архитектуры не выработано.
Согласно международному стандарту IEEE-1471 «Архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы».
Этот же стандарт определяет представление архитектуры 
(architectural description) как согласованный набор документов, 
описывающий архитектуру с точки зрения определенной группы 
заинтересованных лиц с помощью набора моделей. При этом возможно несколько представлений архитектуры, отражающих интересы различных групп заинтересованных лиц. Стандарт рекомендует для каждого представления фиксировать отраженные в нем 
мнения и интересы, роли лиц, которые заинтересованы в таком 
взгляде на ПС, причины, обусловившие такую точку зрения, несоответствия между элементами одного суждения или между различными пониманиями, а также различную служебную информацию 
об источниках информации, датах создания документов и пр.
Стандарт предписывает применение архитектуры ПС для решения следующих задач:
 
• анализ альтернативных проектов системы;
 
• планирование перепроектирования системы, внесение изменений в ее организацию;
 
• общение по поводу системы между различными организациями, 
вовлеченными в ее разработку, эксплуатацию, сопровождение, 
приобретающими систему или продающими ее;
 
• выработка критериев приемки системы при ее сдаче в эксплуатацию;
3

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

 
• аппаратного обеспечения в терминологии компьютерной и телекоммуникационной техники;
 
• информационного обеспечения;
 
• организационного обеспечения в части бизнес-процессов, в том 
числе на уровне персональной ответственности.
Успешная реализация сложной ПС зависит также от грамотного использования технологий и инструментальных средств, аналогов которых в практике программной инженерии ранее не было 
(в частности, унифицированного языка моделирования UML), применения архитектурных шаблонов и базовых фреймворков. 
Золотой век архитектуры ПО, началом которого считается 
1992 год, продолжается и профессиональное сообщество программистов все еще ищет ответы на вопросы: в чем заключается роль 
разработчика архитектуры программного обеспечения? Какие основные действия должен выполнять разработчик архитектуры? 
В чем преимущества разработки архитектуры? 
В результате изучения дисциплины студент должен:
знать 
 
• современные архитектуры программных систем; 
 
• представления и модели жизненного цикла программных систем; 
 
• методы, технологии и средства разработки архитектуры сложных программных систем;
уметь 
 
• решать задачи, возникающие на различных фазах жизненного 
цикла программных систем, связанных с проектированием их 
архитектуры; 
владеть 
 
• навыками использования современных case-средств, применяемых на различных фазах проектирования архитектуры программных систем;
 
• способностью и готовностью использовать свои знания в профессиональной деятельности.
Книга адресована студентам технических специальностей 
по укрупненной группе специальностей «Информатика и вычислительная техника». Может быть использована для самообразования.

Глава 1. 
АРХИТЕКТУРА КАК ФОРМА 
КОНЦЕПТУАЛЬНОГО СУЩЕСТВОВАНИЯ 
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
1.1. ОПРЕДЕЛЕНИЯ АРХИТЕКТУРЫ ПРОГРАММНОГО 
ОБЕСПЕЧЕНИЯ И ЕЕ ЗНАЧИМОСТЬ
Изначально понятие архитектура понималось исключительно 
как искусство и наука строить, проектировать здания и сооружения 
(включая их комплексы). Архитектурой обозначали и совокупность зданий и сооружений, создающих пространственную среду 
для жизни и деятельности человека в соответствии с его устремлениями, а также современными техническими возможностями и эстетическими воззрениями. В архитектуре неразрывно взаимосвязаны 
функциональные (назначение, польза), технические (прочность, долговечность) и эстетические (красота) свойства объектов.  
Задача архитектора (в узком смысле) состоит в разработке архитектурного раздела проектной документации на строительство, 
создании соответствующих рабочих чертежей и авторском надзоре 
за реализацией архитектурного проекта.
Причем в архитектуре важен не только (и не столько) внешний 
вид сооружения. Важнейшим оказываются его функцинальность, 
надежность, использование при строительстве современных материалов и технологий, внутренние инженерные коммуникации, 
связь с окружающей средой, простота обслуживания и ремонта.
Красиво звучащий термин архитектура впоследствии начали 
к месту и не к месту использовать практически во всех областях 
деятельности людей. «Архитектура» принадлежит к числу тех нарочито эффектных слов, которые употребляются преимущественно 
для обозначения чего-то, считающегося значительным и серьезным. 
Термин архитектура пытаются трактовать все, кому не лень, и всяк 
на свой лад и в машиностроении, и в политике, и, наконец, в программировании. Причем в программировании понятие архитектуры 
оказалось наиболее многострадальным. 
Сразу договоримся: архитектура — весьма субъективное понятие и оно, как правило, отображает общую точку зрения команды 
разработчиков на результаты проектирования системы. Обычно это 
согласие в вопросе идентификации главных компонентов системы 
и способов их взаимодействия, а также выбор таких решений, ко6

торые интерпретируются как основополагающие и не подлежащие 
изменению в будущем. 
Термин архитектура программного обеспечения как концепция 
и как квинтессенция структуры был впервые определен в научноисследовательской работе Эдсгера Дейкстры в 1968 г. и Дэвида 
Парнаса в начале 1970-х гг. Эти ученые подчеркнули, что структура программного обеспечения играет важную роль и является 
критическим фактором в процессе разработки. Популярность исследований в этой области возросла в начале 1990-х гг., и  основной 
акцент был связан с архитектурными стилями (в том числе — паттернами), языками описания архитектуры, документированием архитектуры. Были выделены такие элементы в архитектуре ПО, как 
компоненты, коннекторы, стили и пр. 
Создание архитектуры ПО не самоцель, а лишь один из этапов 
проектирования ПО. Проектирование — инженерная деятельность 
в рамках жизненного цикла ПО, в которой на основе анализа требований создается описание внутренней структуры ПО. Что служит, 
в свою очередь, основой для конструирования ПО как такового. Результат процесса проектирования — дизайн ПО. 
Программный дизайн подразумевает декомпозицию программной системы и описание ее в виде организованной структуры компонент и интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна является тот уровень детализации 
компонентов, который позволяет заняться конструированием.
Термины «дизайн» и «архитектура» могут использоваться взаимозаменяемым образом, но чаще говорят о дизайне как о целостном 
взгляде на систему. 
Один из известных специалистов в программной инженерии 
Том ДеМарко предложил терминологическое разделение различных видов дизайна ПО: 
 
• I-дизайн (I-design, invention) — создание высокоуровневой 
концепции, видения того, что собой будет представлять программная система; данный вид дизайна является результатом 
процесса анализа требований и их трансформации в подходы 
к реализации;
 
• D-дизайн (D-design, decomposition design) — декомпозиция 
структуры программного обеспечения в виде набора фрагментов или компонент; 
 
• FP-дизайн (FP-design, family pattern design) — семейство архитектурных представлений, базирующихся на паттернах.
В области информационных технологий и вычислительной техники следует различать области применения термина «архитектура»:
7

 
• архитектура программного обеспечения — множество формальных описаний, необходимых для рассуждения о программ 
ной 
системе и включающих элементы системы, связи между ними 
и свойства этих элементов и связей; 
 
• архитектура компьютера — концептуальная структура вычислительной машины, определяющая проведение обработки информации и включающая методы преобразования информации 
в данные и принципы взаимодействия технических средств 
и программного обеспечения; 
 
• микроархитектура — способ, которым данная архитектура набора команд реализована в процессоре (SPARC, x86 и т.д.);
 
• архитектура набора команд — часть архитектуры компьютера, 
определяющая программируемую часть ядра микропроцессора; 
 
• архитектура процессора — количественная составляющая компонентов микроархитектуры вычислительной машины (процессора компьютера) (например, регистр флагов или регистры 
процессора), рассматриваемая IT-специалистами в аспекте прикладной деятельности;
 
• архитектура данных — способы взаимодействия систем и хранения данных.
Понятие архитектура ПО тесно связано с термином система. 
Большой российский энциклопедический словарь дает нам следуюшую трактовку значения. Система — множество элементов, находящихся в отношениях и связях друг с другом, которое образует 
определенную целостность и единство элементов. Применение 
этого термина подчеркивает упорядоченность, наличие закономерностей построения, функционирования и развития. 
В определение системы входят и характеризуют ее строение основные понятия: 
 
• элемент — предел разбиения системы на составляющие с точки 
зрения решения конкретной задачи;
 
• компонент, подсистема — относительно независимая часть 
системы, обладающая свойствами системы и, в частности, имеющая подцель;
 
• связь, отношение — ограничение степени свободы элементов: 
элементы, вступая во взаимодействие друг с другом, могут утрачивать (или, наоборот, приобретать) часть свойств или степеней 
свободы, которыми они потенциально обладали; система как целое при этом приобретает новые свойства;
 
• структура — компоненты и связи, которые мало меняются 
при текущем функционировании системы и обеспечивают существование системы и ее основных свойств. Структура харак8

теризует организованность системы, устойчивую во времени 
упорядоченность элементов и связей;
 
• цель — в зависимости от контекста имеет разное наполнение: 
«идеальные устремления», «конечный результат», «побуждение 
к деятельности» и  т.д.
Всякая система динамична, функционирование и развитие 
систем характеризуется следующими понятиями:
 
• состояние — мгновенная «фотография», фиксация значений параметров в определенный момент времени;
 
• поведение — закономерности перехода системы из одного состояния в другое (как известные, так и не известные заранее), 
определяемые как взаимодействием с внешней средой, так и целями самой системы;
 
• развитие, эволюция — изменение системы во времени, при котором могут меняться не только ее состояние, но и структура, поведение и даже цель;
 
• жизненный цикл — стадии процесса развития системы начиная 
с момента возникновения необходимости в такой системе и заканчивая ее исчезновением;
 
• внешняя среда — множество элементов, которые не входят в систему, но изменение их состояния вызывает изменение поведения системы. Взаимодействие системы с внешней средой реализуется через условные точки — входы и выходы. На входы 
системы поступают из внешней среды материальные, энергетические и информационные потоки, система преобразует эти потоки и передает их через выходы во внешнюю среду.
Существует множество определений понятия «архитектура ПО». 
Одного и безоговорочно принятого определения архитектуры 
не существует. Наиболее богатая коллекция вариантов употреблений этого термина представлена на сайте SEI1, где каждому, кто 
считает, что он сформулировал это понятие более точно, предоставлена возможность включить свое определение в общую коллекцию.
Мы будем придерживаться следующего определения.
Архитектура программного обеспечения (software architecture) — это 
структура программы или вычислительной системы, которая включает 
программные компоненты (элементы), видимые снаружи свойства этих 
компонентов, а также отношения (взаимодействия) между ними. Архитектура затрагивает не только структуру и поведение, но также использование, функциональность и другие аспекты. 
1 
URL: http://www.sei.cmu.edu/architecture/defi
 nitions.html
9

Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между стейкхолдерами 
(stakeholders — лица, заинтересованные в проекте), позволяет зафиксировать принятые на ранних этапах проектирования решения 
о высокоуровневом дизайне системы и использовать компоненты 
этого дизайна и шаблоны повторно в других проектах.
Причем архитектура программного обеспечения не может быть 
описана в виде какой-либо одной диаграммы, приблизительно отражающей функциональную или структурную декомпозицию системы. Программная архитектура — многогранный подход, гарантирующий, что программное обеспечение будет отвечать своему 
предназначению.
Создание архитектуры ПО — реализация нефункциональных 
требований к системе, в то время как проектирование ПО является 
реализацией функциональных требований.
Архитектура ПО, которую также можно представить себе в виде 
разработки стратегии, — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование 
системы, таких как выбор парадигмы программирования, архитектурных стилей, стандартов разработки ПО, основанных на использовании компонентов, принципов проектирования, и ограничения, 
накладываемые государственным законодательством. Детальное 
проектирование, т.е. разработка тактики, — это деятельность, связанная с определением локальных ограничений проекта, таких как 
шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга1.
Университетом программного обеспечения Университета Карнеги-Меллона предложено следующее толкование ряда позиций 
определения архитектуры:
 
• архитектура в любой версии определяет структуру. Разумеется, 
архитектура не сводится только к структурам (деление на части, 
элементы, интерфейсы, связи, взаимодействие), но структурный 
аспект в ее содержании и его материализации является наиболее 
существенным;
1 
DoD Architecture Framework and Software Architecture Workshop Report. 
March 2003. URL: http://www.ichnet.org/DODAF%20SEI%20report.pdf; 
TOGAF: The Open Group Architectural Framework. URL: www.togaf.org; 
FEAF: FEA Frameworks. URL: www.eaframeworks.com/FEAF/index.html; 
IEEE 1471, 2000: IEEE Recommended Practice for Architectural Description 
of Software-Intensive Systems. URL: https://pdfs.semanticscholar.org/e74f/0b
588e95d5e3c5c5176617026f48a63655d5.pdf
10