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

Москва
ИНФРА-М
2013

АРХИТЕКТУРА  

И ПРОЕКТИРОВАНИЕ 

ПРОГРАММНЫХ

СИСТЕМ

МОНОГРАФИЯ

 С.В. НазароВ

Назаров С.В. 
Архитектура и проектирование программных систем: Монография.  — М.: ИНФРА-М, 2013. – 351 с. — (Научная мысль).

ISBN 978-5-16-005735-4

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

ББК 22.18

УДК 004.42(075.4)
ББК 22.18
 
Н19

© Назаров С.В., 2013
ISBN 978-5-16-005735-4

Н19

Рецензенты:
доктор технических наук, профессор Московского НИУ электронной 
техники Л.Г. Гагарина;
доктор технических наук, профессор Московского государственного университета путей сообщения  (МИИТ) А.Б. Барский 

Материалы, отмеченные знаком 
, 
доступны в электронно-библиотечной системе znanium по адресу:  
http://znanium.com

Предисловие

За более чем шестидесятилетнюю эволюцию аппаратное обеспечение 

компьютеров достигло небывалого прогресса. Эмпирическое наблюдение, сделанное Г. Муром в 1965 году, в современной трактовке говорит 
об удвоении производительности компьютеров каждые два года. Современному специалисту (пользователю) доступна такая вычислительная 
мощность, которую 10 – 15 лет назад имели немногие научные учреждения. Однако эти вычислительные мощности невозможно использовать без 
программных систем (ПС). И в этой области, несмотря на значительный 
рост доступности аппаратных ресурсов, наблюдаются значительные проблемы. 

Надо сказать, что компьютерная теория и практика с момента своего 

образования столкнулись с проблемами, связанными со сложностью программных систем. Первоначально проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин "архитектура программного обеспечения" является относительно 
новым для индустрии разработки ПС, фундаментальные принципы в этой 
области неупорядоченно применялись пионерами разработки программного обеспечения, начиная с начала 1980-х годов. Считается, что начало 
архитектуре программного обеспечения как концепции было положено в 
научно-исследовательской работе Э. Дейкстры в 1968 году и Д. Парнаса в 
начале 1970-х. Эти ученые подчеркнули, что структура системы программного обеспечения имеет существенное значение, и построение правильной структуры критически важно.

По данным американских исследователей, в эти годы только 14% про
ектов по созданию ПС завершались успешно (т.е. с удовлетворением требований заказчика,  завершением в срок и соблюдением бюджета). Сегодня, после нескольких десятилетий эволюции языков программирования, 
инструментальных средств разработки, практически неограниченной доступности машинного времени, ситуация практически не изменилась. Согласно статистике о состоянии дел в программной индустрии в 2008 году, 
опубликованной компанией Standish Group, из 30 тыс. программных проектов 32% проектов завершились успешно, 44% проектов завершились с 
проблемами (превысили бюджет, сроки и пр.) и 24% проектов полностью 
провалились. 

На сегодняшний день до сих пор нет согласия в отношении четкого 

определения термина "архитектура программного обеспечения". Являясь 
в настоящий момент своего развития дисциплиной без четких правил о 
"правильном" пути создания системы, проектирование архитектуры ПС 
все еще является смесью науки и искусства. Популярность изучения этой 
области 
возросла 
с 
начала
1990-х 
годов 
вместе 
с 
научно
исследовательской работой по исследованию архитектурных стилей 
(шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов проектирования. Известна книга М. Шоу и 
Д. Гэрлана из университета Carnegie Mellon под названием "Архитектура 

программного обеспечения: перспективы новой дисциплины в 1996 году". В книге выдвинуты некоторые концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и 
др. В калифорнийском университете Институт Ирвайна по исследованию 
ПО в первую очередь исследуются архитектурные стили, языки описания 
архитектуры и динамические архитектуры. Результатами подобных исследований являются популярные монографии, например, книга Л. Басса 
и др. “Архитектура программного обеспечения на практике”. Однако таких трудов не так-то много, тем более в отечественной литературе. В этом 
свете данная монография, по мнению автора, в некоторой степени  снижает дефицит таких публикаций.

Первая глава монографии по своей сути является вводной в проблему 

архитектурного проектирования. В ней рассматривается широкий круг 
вопросов, связанных с проблемами создания больших программных систем: особенности разработки сложных (больших) программных систем, 
инженерный подход к разработке ПС, становление и развитие программной инженерии, развитие технологий программирования, индустрия программного обеспечения. Завершается глава рассмотрением современного 
состояния  ИТ-индустрии в России. 

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

Сегодня в мире существует большое количество различных процессов 

и технологий для создания ПС, рассматривающих полный жизненный 
цикл (ЖЦ) проекта разработки ПС и сочетающих в себе научный подход, 
серьезную базу исследований и имеющих историю реального использования. В третьей главе монографии детально рассматриваются элементы 
ЖЦ ПС, обобщенные и сформулированные на основе анализа массы публикаций. Освещено само понятие жизненного цикла программных систем, основные, вспомогательные и организационные процессы ЖЦ ПС и 
их взаимосвязь. Большое внимание уделено современным прогрессивным 
видам моделей ЖЦ ПС, технологиям и инструментам создания программных систем, в том числе рациональному унифицированному процессу (RUP),  SCRAM-методологии и  Agile-методологии. Особое место в 
этом списке занимает технология и инструменты компании IBM Rational 

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 как языке моделирования сложных систем. В заключение главы дана последовательность разработки предварительного 
внешнего проекта, включающая описание процесса внешнего проектирования, проектирование взаимодействия с пользователем, подготовку и  
проверку правильности внешних спецификаций.

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

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

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

Седьмая 
глава 
посвящена 
изложению 
вопросов 
технико
экономического анализа проектов программных систем. Содержание главы отвечает на ряд важных вопросов такого анализа при планировании 
жизненного цикла программных систем. В целом это добротный материал, обобщающий результаты исследований последних лет, опубликованных в трудах ведущих специалистов. В материале главы рассматриваются 
вопросы первичного технико-экономического обоснования разработки 
ПС, 
методы 
оценки 
размеров 
проектов 
на 
основе 
размерно
ориентированных и функционально-ориентированных метрик, на основе 
LOC- и FP-метрик, оценка по конструктивной модели стоимости. Рассмотрены известные модели композиции приложения,  раннего этапа 
проектирования, этапа постархитектуры. В заключение дана оценка компромиссной стоимости программной  системы со стороны заказчика и 
исполнителя проекта.

Интересной, на взгляд автора, является восьмая заключительная глава, 

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

Автор  

Глава 1
ВВЕДЕНИЕ. ПРОБЛЕМЫ СОЗДАНИЯ
БОЛЬШИХ

ПРОГРАММНЫХ СИСТЕМ

1.1. Особенности разработки сложных (больших) программных 

систем

Из года в год увеличиваются разнообразие и сложность систем, полу
чивших в международной научно-технической практике название систем, 
интенсивно использующих программное обеспечение (Software Intensive 
Systems,  SIS). В системах такого рода функциональный потенциал определяется программным обеспечением (ПО) или зависит от ПО в существенной мере [23]. Общепризнанный законодатель в области исследований 
и разработок SIS институт программной инженерии университета Карнеги-Меллон (Software Engineering Institute, SEI) относит к классу SIS системы, в которых программные системы представляют существенный сегмент по следующим позициям: функциональность системы, ее стоимость, 
риски в процессе разработки, время разработки.

В таких системах программные компоненты взаимодействуют друг с 

другом и компонентами и подсистемами другой природы, датчиками, 
приборами и людьми, вовлеченными в процессы использования SIS. К 
числу SIS, например, относятся разнородные автоматизированные системы управления, встроенные бортовые транспортные системы, телекоммуникационные и корпоративные системы, в том числе и на базе webсервисов. Для разработок SIS типичны крупномасштабные проекты ─ 
десятки или сотни разработчиков, месяцы или годы разработки, сотни 
тысяч или десятки миллионов долларов, комплексирование из многочисленных разнородных подсистем, большая часть из которых включает 
программные системы. 

Такие программные системы называют сложными или “большими”, 

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

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

вать или расширять. Разработка подобных программ скорее утомительна, 
чем сложна, так что изучение этого процесса нас не интересует [6]. 

Какого-либо одного формального признака, отличающего обычную 

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

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

Обычно сложная программа обладает следующими свойствами [4, 18]: 
1) программа решает одну или несколько связанных прикладных за
дач, зачастую сначала не имеющих четкой постановки, настолько важных 
для каких-либо лиц или организаций, что те приобретают значимые выгоды от ее использования;

2) программа не предназначена для решения каких-либо прикладных 

задач, но от нее зависит эффективное решение этих прикладных задач. 
Это системные программы, например, операционные системы, системы 
управления базами данных, различные инструментальные системы и т.п.;

3) существенно, чтобы программа была удобной в использовании. В 

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

4) программа должна обладать высокой производительностью, высо
кой реактивностью или удовлетворять другим требованиям, в противном 
случае ее использование по назначению (на реальных данных) может 
привести к значимым для пользователей потерям;

5) программа должна обладать высокой надежностью. Неправильная 

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

6) для выполнения своих задач программа должна удовлетворять тре
бованиям совместимости, переносимости и интеграции  с другими программами и программно-аппаратными системами и обеспечивать работу 
на разных платформах; 

7) пользователи, работающие с программой, могут приобретать до
полнительные выгоды от того, что программа развивается, в нее вносятся 
новые функции и устраняются ошибки. Поэтому необходимо наличие 
проектной документации, позволяющей развивать ее, возможно, вовсе не 
тем разработчикам, которые ее создавали, без больших затрат на обратную разработку (реинжиниринг); 

8) в разработку программы вовлечено значительное количество людей 

(десятки и сотни человек). Большую программу практически невозможно 
написать с первой попытки, с небольшими усилиями и в одиночку; 

9) большая программа имеет намного большее количество ее возмож
ных пользователей по сравнению с небольшими программами, и еще 
больше тех лиц, деятельность которых будет так или иначе затронута ее 
работой и результатами. 

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

Рост спроса на программные системы (ПС) является следствием того, 

что по мере удешевления, повышения надежности и увеличения объема 
производства компьютеров автоматизация труда человека с помощью 
компьютера становится все более выгодной. Эту тенденцию, отмеченную 
Б. Боэмом еще в 80-е годы прошлого века и подкрепленную нашим временем, иллюстрирует рис. 1.1, на котором показано расширение масштабов использования компьютеров и увеличение социального влияния этого 
использования. Надо сказать. Часто жизнь вносит свои поправки и ожидаемые события опережают время.

Рис. 1.1. Тенденция расширения масштабов использования

компьютеров

В США к 1985 году примерно 40 % работающих использовали в своей 

профессиональной деятельности компьютер и программные системы (ряд 
1 на рис. 1.1), не обязательно зная, как эти средства функционируют [4]. 
По данным [16] в США в 2010 году уровень использования компьютеров 
составил 90%, в Европе — 70%. Однако эта тенденция усиливается, и к 
2015 году около 95% работающих  будут использовать компьютеры в 

своей повседневной деятельности. При этом более половины пользователей будут иметь определенные знания о работе компьютера.

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

В нашей стране с 1 января 2010 года все организации, обрабатываю
щие в своих информационных системах персональные данные физических лиц (сотрудников, клиентов, партнеров и т.п.), независимо от размера и формы собственности должны выполнять требования, установленные законом № 152-ФЗ «О персональных данных» [22]. Последние изменения по защите персональных данных были внесены федеральным законом № 261-ФЗ от 25.07.2011. Этим законом была уточнена сфера действия Федерального закона «О персональных данных», используемые в нём 
основные понятия, принципы и условия обработки персональных данных.

Все возрастающее воздействие компьютеров на благосостояние чело
века предъявляет несколько важных требований к созданию программных систем. Эти требования состоят в необходимости такой разработки и 
сопровождения ПС, которые гарантируют, что вычислительные системы 
должны быть:

исключительно надежными;
удобными в использовании;
безопасными и труднодоступными для злоупотреблений;
проверяемыми;
оставляющими главную (решающую) роль за человеком, а не компь
ютером.

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

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

Стоимость и качество производимого программного продукта опреде
ляется уровнем развития инженерного программирования. Важность инженерного программирования обусловливается двумя основными тенденциями:

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