Файл: Инфрам.pdf

1
С.В. Назаров
АРХИТЕКТУРА И ПРОЕКТИРОВАНИЕ
ПРОГРАММНЫХ СИСТЕМ
Москва
ИНФРА-М
2013

2
УДК 004.14
ББК 32.973.26-018
РЕЦЕНЗЕНТЫ: доктор технических наук, профессор
Московского НИУ электронной техники Л.Г. Гагарина, доктор технических наук, профессор Московского государственного университета путей сообщения (МИИТ) А.Б. Барский
Назаров С.В.
Архитектуры и проектирование программных систем: моно- графия /С.В. Назаров. — М.: ИНФРА-М, 2013. — *** с.
ISBN 978-5-16-
В монографии рассматриваются технологии и проблемы создания больших программных систем, их архитектуры и жизненный цикл. Основное внимание обращено на разработку и анализ требований, определение спецификаций, методы и средства проектирования архитектуры программных систем и технико- экономический анализ проектов. Уделено значительное внимание рефакторингу программных систем, в том числе архитектурному рефакторингу.
Для аспирантов, преподавателей технических вузов и специалистов, зани- мающихся разработкой программных систем
ББК
ISBN 978-5-16-
© Назаров С.В., 2013
Подписано в печать 25.07.2010. Формат 60x88/16.
Гарнитура Newton. Бумага офсетная.
Усл. печ. л. 15,0. Уч.изд. л. 18,72.
Тираж 500 экз. Заказ №
Цена свободная.
Издательский Дом «ИНФРА-М»
127282, Москва, ул. Полярная, д. 31в.
Тел.: (495) 3800540, 3800543. Факс: (495) 3639212
E-mail: books@infra-m.ru http://www.infra-m.ru
Отпечатано по технологии «печать по требованию»
Тел.: (495) 363-92-15; e-mail: info@rior.ru www.rior.ru

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

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

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

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

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

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