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

Ñ.Â. ÍÀÇÀÐÎÂ
АРХИТЕКТУРА 
И ПРОЕКТИРОВАНИЕ 
ПРОГРАММНЫХ СИСТЕМ
МОНОГРАФИЯ
2-е издание, переработанное и дополненное
Москва
ИНФРА-М
2020

УДК 004.2(075.4)
ББК 32.973.26-02
 
Н19
Р е ц е н з е н т ы: 
Л.Г. Гагарина — доктор технических наук, профессор Национального 
исследовательского университета «Московский институт электронной 
техники» (МИЭТ);
А.Б. Барский — доктор технических наук, профессор Московского государственного университета путей сообщения  (МИИТ) 
Н19
Назаров С.В.
Архитектура и проектирование программных систем : монография / С.В. Назаров. — 2-е изд., перераб. и доп. — Москва : ИНФРА-М, 
2020. — 374 с. — (Научная мысль). — DOI 10.12737/18292.
ISBN 978-5-16-011753-9 (print)
ISBN 978-5-16-104150-5 (online)
В монографии рассматриваются технологии и проблемы создания 
больших программных систем, их архитектуры и жизненного цикла. 
Основное внимание обращено на разработку и анализ требований, определение спецификаций, методы и средства проектирования архитектуры 
программных систем. Уделено значительное внимание рефакторингу программных систем, в том числе архитектурному рефакторингу.
Для аспирантов, преподавателей технических вузов и специалистов, 
занимающихся разработкой программных систем.
УДК 004.2(075.4)
ББК 32.973.26-02
© Назаров С.В., 2016
ISBN 978-5-16-011753-9 (print)
ISBN 978-5-16-104150-5 (online)

Предисловие
Термин «архитектура программного обеспечения» является относительно новым. Являясь в настоящий момент дисциплиной без четких
правил, проектирование архитектуры программных систем (ПС) – все
еще смесь науки и искусства. Важность начального этапа создания ПС – 
определения ее архитектуры – трудно переоценить. Известно, что ошибки, допущенные на начальных этапах проектирования ПС, могут свести
на нет успех всего проекта. 
В монографии рассмотрен широкий круг вопросов, связанных с проблемами создания больших ПС: инженерный подход к разработке ПС, 
становление и развитие программной инженерии, развитие технологий
программирования, точки зрения широкого круга лиц, заинтересованных в ПС, которые могут быть объединены в архитектуре ПС. Это аргумент в целесообразности создания архитектуры ПС еще до этапа разработки ПС.  
Существует большое количество технологий создания ПС, рассматривающих полный жизненный цикл (ЖЦ) разработки ПС и сочетающих
в себе научный подход, серьезную базу исследований и имеющих историю реального использования. В  предлагаемой монографии детально
рассматриваются элементы ЖЦ ПС, обобщенные и сформулированные
на основе анализа массы публикаций.  
Значительная часть монографии посвящена вопросам проектирования ПС в части определения требований и целей программного продукта. Этот материал представляет собой обобщение опубликованных монографий и статей, а также собственных исследований автора. Процесс
проектирования рассматривается как последовательная трансляция требований, предъявляемых к ПС. Предложены формализованная схема
процесса проектирования и авторский подход, который может быть использован для выбора требований, предъявляемых к системе. Даны постановка задачи и принципы разработки требований, включая бизнесмоделирование, определение
функциональных
и нефункциональных
требований, предъявляемых к ПС. 
Дан материал по вопросам разработки предварительного внешнего
проекта ПС: представление и анализ требований, роль моделирования
в определении требований и спецификаций, разработка ПС, управляемая моделями. Продолжена формальная схема проектирования применительно к описанию спецификаций. Рассмотрен структурный и объектный подход в анализе требований и определении спецификаций, в том
числе метод функционального моделирования, функциональные диаграммы, диаграммы потоков данных и др., достаточные сведения о языке UML как языке моделирования сложных систем. 
Дан материал по проектированию архитектуры ПС. Изложены теоретические основы методологии проектирования, модульно-интерфейсный подход и модульное программирование, вопросы оценки сложности ПС, представление архитектуры ПС на основе модульно-интерфейс3

ного, объектно-ориентированного и компонентного подходов. Предложено формальное определение слоев ПС. Показано, что структурный
подход  правомочен при разработке ПС на основе объектно ориентированной и компонентной методологии. 
Рассмотрен широкий круг вопросов, связанных с рефакторингом
объектно ориентированных программ. Объясняется суть рефакторинга, 
его связь с производительностью и качеством ПС. Излагаются ситуации, в которых следует применять рефакторинг, его методы. Уделено
внимание формальным методам рефакторинга, позволяющим автоматизировать процессы рефакторинга. Рассматриваются вопросы построения
архитектуры ПС по ее программному коду, рефакторинг архитектуры
многослойной иерархической ПС, паттерн выделения слоев. Предлагается подход к решению задачи оптимизации архитектуры программной
системы в интересах повышения производительности. 
Данная монография является вторым изданием, переработанным
и дополненным. 
4

Введение
За более чем шестидесятилетнюю эволюцию аппаратное обеспечение
компьютеров достигло небывалого прогресса. Эмпирическое наблюдение, сделанное Г. Муром в 1965 г., в современной трактовке говорит об
удвоении производительности компьютеров каждые два года. Современному специалисту (пользователю) доступна такая вычислительная мощность, которую 10–15 лет назад имели немногие научные учреждения. 
Однако эти вычислительные мощности невозможно использовать без
программных систем. И в этой области, несмотря на значительный рост
доступности аппаратных ресурсов, наблюдаются значительные проблемы.  
Надо сказать, что компьютерная теория и практика с момента своего
образования столкнулись с проблемами, связанными со сложностью программных систем. Первоначально проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПС, фундаментальные принципы в этой
области неупорядоченно применялись пионерами разработки программного обеспечения, с начала 1980-х гг. Считается, что начало архитектуре
программного обеспечения как концепции было положено в научно-исследовательской работе Э. Дейкстры в 1968 г. и Д. Парнаса в начале  
1970-х. Эти ученые подчеркнули, что структура системы программного
обеспечения имеет существенное значение, и построение правильной
структуры критически важно. 
По данным американских исследователей, в эти годы только 14% проектов по созданию ПС завершались успешно (т.е. с удовлетворением требований заказчика,  завершением в срок и соблюдением бюджета). Сегодня, после нескольких десятилетий эволюции языков программирования, 
инструментальных средств разработки, практически неограниченной доступности машинного времени, ситуация практически не изменилась. Согласно статистике о состоянии дел в программной индустрии в 2008 г., 
опубликованной компанией Standish Group, из 30 тыс. программных проектов 32% проектов завершились успешно, 44% проектов завершились
с проблемами (превысили бюджет, сроки и пр.) и 24% проектов полностью провалились.  
На сегодняшний день до сих пор нет согласия в отношении четкого
определения термина «архитектура программного обеспечения». Являясь
в настоящий момент своего развития дисциплиной без четких правил о
«правильном» пути создания системы, проектирование архитектуры ПС
все еще является смесью науки и искусства. Популярность изучения этой
области возросла с начала 1990-х гг. вместе с научно-исследовательской
работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры и формальных методов проектирования. Известна книга М. Шоу и Д. Гэрлана из университета Carnegie Mellon под названием «Архитектура программного обеспече5

ния: перспективы новой дисциплины в 1996 г.». В книге выдвинуты некоторые концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и др. В Калифорнийском университете (Ирвайн), занимающемся изучением ПС, в первую очередь исследуются архитектурные стили, языки описания архитектуры и динамические архитектуры. Результатами подобных исследований являются популярные монографии, например книга Л. Басса и др. «Архитектура программного обеспечения на практике». Однако таких трудов не так-то
много, тем более в отечественной литературе. В этом свете данная монография, по мнению автора, в некоторой степени  снижает дефицит таких
публикаций. 
Первая глава монографии вводит в проблему архитектурного проектирования. В ней рассматривается широкий круг вопросов, связанных
с проблемами создания больших программных систем: особенности разработки сложных (больших) программных систем, инженерный подход
к разработке ПС, становление и развитие программной инженерии, развитие технологий программирования, индустрия программного обеспечения.  
Вторая глава – одна из центральных в монографии.   В ней рассматриваются все аспекты архитектур современных программных систем. С точки зрения пользователя программной архитектуры (заинтересованного
лица – заказчика, разработчика ПС,  специалистов по тестированию, специалистов по развертыванию и сопровождению ПС, а также конечных
пользователей), эта архитектура дает направление для рассмотрения и решения задач, связанных со специальностью каждого такого пользователя. 
Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения, является аргументом
в защиту необходимости и целесообразности создания архитектуры ПС
еще до этапа разработки ПС. Именно в этом направлении в монографии
излагаются архитектуры ПС. В ней дается понятие архитектуры программной системы, отмечаются причины ее важности, откуда и как появляется архитектура,  кто и что на нее влияет, что определяет и на что
влияет архитектура. Заключительный материал главы посвящен рассмотрению некоторых архитектурных представлений программных систем. 
Сегодня в мире существует большое количество различных процессов
и технологий для создания ПС, рассматривающих полный жизненный
цикл проекта разработки ПС и сочетающих в себе научный подход, серьезную базу исследований и имеющих историю реального использования. 
В третьей главе монографии детально рассматриваются элементы ЖЦ
ПС, обобщенные и сформулированные на основе анализа массы публикаций. Освещены само понятие жизненного цикла программных систем, основные, вспомогательные и организационные процессы ЖЦ ПС и их
взаимосвязь. Большое внимание уделено современным прогрессивным
видам моделей ЖЦ ПС, технологиям и инструментам создания программных систем, в том числе рациональному унифицированному процессу
(RUP),  Scrum-методологии и  Agile-методологии. Особое место в этом
списке занимают технология и инструменты компании IBM Rational 
6

Software. В этом плане интересна заключительная часть главы, в которой
рассматривается управление жизненным циклом приложений и интегрированная среда поддержки создания программных систем (Application 
Lifecycle Management, ALM) на основе комплекса решений IBM Rational 
Software and Systems Delivery, являющихся наиболее полным по спектру
реализованных компонентов ALM,  и проекта  IBM Jazz.  
В четвертой главе рассмотрены вопросы  проектирования программных систем в части определения требований и целей программного продукта. Материал этой главы представляет собой обобщение опубликованных монографий и статей, а также собственных исследований автора. 
Процесс проектирования рассматривается как последовательная трансляция требований, предъявляемых к ПС. Оригинальными являются формализованная схема процесса проектирования, а также предложенный
автором подход, который может быть использован для выбора тех требований, предъявляемых к системе, которые наиболее совместимы
с другими требованиями. Даны постановка задачи и принципы разработки требований, включая бизнес-моделирование, определение функциональных и нефункциональных требований. Рассмотрены вопросы
анализа и управления требованиями, соотношения требований и рисков, 
проверка правильности требований, формирование целей программного
продукта и проекта. 
Пятая глава содержит материал, позволяющий решать вопросы разработки предварительного внешнего проекта программной системы. Здесь
рассмотрены представление и анализ требований, роль моделирования
в определении требований и спецификаций, разработка программных
систем, управляемая моделями. Продолжена формальная схема предыдущей главы применительно к описанию спецификаций. Уделено внимание
инструментам IBM Rational RequisitePro, Rational Software Architect и IBM 
Rational Software Modeler, а также другим средствам IBM. Дан структурный и объектный подход в анализе требований и определении спецификаций, в том числе метод функционального моделирования, функциональные диаграммы, диаграммы потоков данных и др., достаточные  сведения
о языке UML как языке моделирования сложных систем. В заключение
главы дана последовательность разработки предварительного внешнего
проекта, включающая описание процесса внешнего проектирования, проектирование взаимодействия с пользователем, подготовку и  проверку
правильности внешних спецификаций. 
В шестой главе содержится обширный материал по проектированию
архитектуры программных систем. Здесь изложены теоретические основы  методологии проектирования ПС, модульно-интерфейсный подход
и модульное программирование, вопросы оценки сложности программных систем, представление архитектуры программных систем на основе
модульно-интерфейсного,  объектно ориентированного и компонентного
подходов. Интересным и во многом оригинальным, с элементами формализации является материал по оценке сложности ПС и представлению
многослойного программного продукта. Показан подход к формальному
определению слоев программной системы. Большое внимание уделено
7

рассмотрению методов структурного проектирования ПС. Показано, что
структурный подход в ряде случаев правомочен при разработке программных систем на основе объектно ориентированной и компонентной
методологии. В заключение главы дано описание методики разработки
модульной (компонентной) архитектуры программной системы на основе
формализованной схемы процесса проектирования, изложенной в четвертой главе. Этот материал отличается новизной и оригинальностью. 
Важной, на взгляд автора, является седьмая, заключительная глава, 
посвященная актуальной в последнее время тематике рефакторинга программных систем. В ней рассматривается большой круг вопросов, связанных с рефакторингом объектно ориентированных программных систем. 
Объясняется, что такое рефакторинг и как он связан с производительностью и проектированием ПС, подробно  излагаются ситуации, в которых
следует применять рефакторинг, а также методы рефакторинга. Уделено
внимание формальным методам рефакторинга, позволяющим автоматизировать процессы рефакторинга. Вводится понятие уровня рефакторинга
и высшего его уровня – архитектурного рефакторинга. Определяются ситуации, в которых необходим архитектурный рефакторинг. В заключение
главы рассматриваются вопросы построения архитектуры ПС по ее программному коду, рефакторинг архитектуры многослойной иерархической
ПС, слои модулей (компонентов) в архитектуре ПС и паттерн выделения
слоев. Предлагается подход к решению задачи оптимизации архитектуры
программной системы в интересах повышения производительности. Это
наиболее интересная часть главы, в направлении которой предполагается
дальнейшая работа автора. 
8

Глава 1 
ПРОБЛЕМЫ СОЗДАНИЯ БОЛЬШИХ ПРОГРАММНЫХ  
СИСТЕМ
1.1. Особенности разработки сложных (больших) программных
систем
Из года в год увеличиваются разнообразие и сложность систем, получивших в международной научно-технической практике название систем, 
интенсивно
использующих
программное
обеспечение, – 
(Software 
Intensive Systems  (SIS). В системах такого рода функциональный потенциал определяется программным обеспечением (ПО) или зависит от ПО
в существенной мере [23]. Общепризнанный законодатель в области исследований и разработок SIS, Институт программной инженерии Университета Карнеги-Меллон (Software Engineering Institute, SEI), относит
к классу SIS системы, в которых программные системы представляют существенный сегмент по следующим позициям: функциональность системы, ее стоимость, риски в процессе разработки, время разработки. 
В таких системах программные компоненты взаимодействуют друг
с другом и компонентами и подсистемами другой природы, датчиками, 
приборами и людьми, вовлеченными в процессы использования SIS. 
К числу SIS, например, относятся разнородные автоматизированные системы управления, встроенные бортовые транспортные системы, телекоммуникационные и корпоративные системы, в том числе и на базе web-сервисов. Для разработок SIS типичны крупномасштабные проекты – десятки или сотни разработчиков, месяцы или годы разработки, сотни тысяч
или десятки миллионов долларов, комплектование из многочисленных
разнородных подсистем, большая часть из которых включает программные системы.  
Такие программные системы называют сложными или большими программными комплексами, программными продуктами. Они отличаются
от небольших не только по размерам (достаточно вспомнить современные операционные системы). Важным для таких систем является наличие
дополнительных факторов. Эти факторы связаны с востребованностью
программных систем и готовностью пользователей платить деньги как за
приобретение самой программы, так и за ее сопровождение и даже за специальное обучение работе с ней.  
Не все программные системы сложны. Существует множество программ, которые задумываются, разрабатываются, сопровождаются и используются одним и тем же человеком. Обычно это начинающий программист или профессионал, работающий изолированно. Нельзя  сказать, 
что все такие системы плохо сделаны или тем более усомниться в квалификации их создателей. Но такие системы, как правило, имеют очень ограниченную область применения и короткое время жизни. Обычно их
лучше заменить новыми, чем пытаться повторно использовать, переделывать или расширять. Разработка подобных программ скорее утомительна, 
чем сложна, так что изучение этого процесса нас не интересует [6].  
9

Какого-либо одного формального признака, отличающего обычную
программу от сложной, не существует. В целом сложные программы выгодно отличаются разнообразием предоставляемого сервиса и количеством обрабатываемой информации. Возможно обозначить лишь некоторые
качественные характеристики, свойственные сложной программе [15]. 
Сложная программа характеризуется также более сложным алгоритмом
обработки событий. В частности, такая программа предполагает некоторую реакцию на вмешательство  пользователя в управляемый процесс
или объект. 
Существенно, что сложные программы предназначены для многократного использования и применения разными пользователями. В связи
с этим следует обратить внимание на ряд необходимых свойств программного обеспечения.  
Обычно сложная программа обладает следующими свойствами [4, 18]:  
1) программа решает одну или несколько связанных прикладных задач, зачастую сначала не имеющих четкой постановки и настолько важных для каких-либо лиц или организаций, что те приобретают значимые
выгоды от ее использования; 
2) программа не предназначена для решения каких-либо прикладных
задач, но от нее зависит эффективное решение этих прикладных задач. 
Это системные программы, например операционные системы, системы
управления базами данных, различные инструментальные системы и т.п.; 
3) существенно, чтобы программа была удобной в использовании. 
В частности, она должна включать достаточно полную и понятную пользователям документацию, возможно, специальную документацию для администраторов, а также набор документов для обучения работе с программой;  
4) программа должна обладать высокой производительностью, высокой реактивностью или удовлетворять другим требованиям, в противном
случае ее использование по назначению (на реальных данных) может
привести к значимым для пользователей потерям; 
5) программа должна обладать высокой надежностью. Неправильная
работа программы может нанести ощутимый ущерб пользователям и другим организациям и лицам, даже если сбои происходят не слишком часто;  
6) для выполнения своих задач программа должна удовлетворять требованиям совместимости, переносимости и интеграции  с другими программами и программно-аппаратными системами и обеспечивать работу
на разных платформах;  
7) пользователи, работающие с программой, могут приобретать дополнительные выгоды от того, что программа развивается, в нее вносятся новые функции и устраняются ошибки. Поэтому необходимо наличие проектной документации, позволяющей развивать ее, возможно, вовсе не тем
разработчикам, которые ее создавали, без больших затрат на обратную
разработку (реинжиниринг);  
8) в разработку программы вовлечено значительное количество людей
(десятки и сотни человек). Большую программу практически невозможно
написать с первой попытки, с небольшими усилиями и в одиночку;  
10