Эволюция сложных программных систем

ВВЕДЕНИЕ
За более чем шестидесятилетнюю эволюцию аппаратное обеспечение компьютеров достигло небывалого прогресса. Эмпирическое наблюдение, сделанное Г. Муром в 1965 году, в современной трактовке говорит об удвоении производительности компьютеров каждые два года. Современному специалисту (пользователю) доступна такая вычислительная мощность, которую 10-15 лет назад имели немногие научные учреждения. Однако эти вычислительные мощности невозможно использовать без программных систем (ПС). И в этой области, несмотря на значительный рост доступности аппаратных ресурсов, наблюдаются значительные проблемы.Надо сказать, что компьютерная теория и практика с момента своего образования столкнулись с проблемами, связанными со сложностью программных систем. Первоначально проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПС, фундаментальные принципы в этой области неупорядоченно применялись пионерами разработки программного обеспечения, начиная с начала 1980-х годов.1 ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ1.1 Общие сведения о программных системах Для правильной организации эффективных процессов разработки ПО и обеспечения высокого качества программных продуктов важно отчетливо понимать и применять при анализе и проектировании принципы системного взаимодействия объектов и субъектов реального мира. Понятие системы постоянно совершенствуется в процессе развития методологических основ исследования окружающей нас реальности. Основоположник теории систем Людвиг фон Берталанфи первоначально определил систему как комплекс взаимодействующих элементов, находящихся в определенных отношениях друг с другом и со средой. При этом под средой понимается все то, что не входит в систему, а система, наоборот, представляет собой конечное множество объектов, целевым образом выделенное из среды. При этом между средой и системой существует множество взаимных связей, с помощью которых реализуется процесс их взаимодействия. Таким образом, при определении системы необходимо исходить из следующего основополагающего принципа: система – это целостное образование, представляющее собой организованное и динамическое множество элементов, свойств и отношений, имеющее системообразующие свойства и взаимодействующее с внешним окружением. Программная система – система, состоящая из частей – компонентов программного обеспечения (рисунок 1). В свою очередь, программное обеспечение, которое существует в совокупности с техническим (аппаратным), математическим, информационным, организационным, методическим и др., является одним из видов обеспечивающих подсистем автоматизированной системы обработки информации и управления (АСОИУ). АСОИУ представляет собой систему обработки данных, основанную на использовании ЭВМ и связанную с управлением теми или иными объектами (предприятиями, организациями, технологическими процессами). Она предназначена для целенаправленного автоматизированного ведения производственных, организационно-административных и технологических процессов с выдачей достоверной технико-экономической и технологической информации.Рисунок 1 – Пример программной системыВ целом можно выделить следующие признаки любой системы, позволяющие различать их среди разнообразных объектов реального мира [3]: − система представляет собой совокупность элементов, которые тоже могут рассматриваться как системы; в свою очередь, исходная система является частью более общей системы, таким образом, система представляется как органическая часть иерархии систем; − система характеризуется наличием интегративных свойств, которые определяют систему в целом, однако не свойственны отдельным ее элементам; − систему отличает наличие существенных, хотя и различных по типу, связей между элементами (совокупность разрозненных частей считать системой нельзя).1.2 Этапы проектирования программных системПри планировании процесса разработки программной системы важное значение имеет выбор стратегии разработки при реализации проектных работ. Существуют три основных стратегии создания ПО: − однократный проход (водопадная стратегия), в ходе которого выполняется линейная последовательность этапов конструирования; − инкрементная стратегия, заключающаяся в изначальном установлении всех пользовательских и системных требований, которые в дальнейшем реализуются в виде последовательности версий; − эволюционная стратегия, при которой программная система также строится в виде последовательности версий, но в начале процесса определены не все требования, они уточняются в результате разработки версий. Классический цикл проектирования реализуется водопадной (каскадной) моделью, представляющей последовательность этапов, при том, что переход на следующий этап происходит после завершения работ на текущем. В оригинальной каскадной модели Ройса эти этапы расположены в таком порядке [4]: − определение требований; − проектирование; − конструирование (реализация, кодирование); − воплощение; − тестирование и отладка (в том числе верификация); − инсталляция; − поддержка. Каскадная модель в чистом виде почти не используется из-за недостаточной гибкости процесса проектирования, однако она определяет логическую последовательность этапов проектирования, применяемую как в итерационных, так и эволюционных моделях. В частности, широкое применение получила V-образная модель, которая была разработана как разновидность каскадной модели. Здесь каждая последующая фаза также начинается по завершению получения результативных данных предыдущей фазы. Однако в данной модели используется комплексный подход к определению фаз процесса проектирования ПО за счет выделения взаимосвязей, существующих между аналитическими фазами и фазами проектирования, предшествующими кодированию, и последующими фазами верификации и тестирования. Схематически данная модель представлена на рисунке 2.Рисунок 2 – Основные этапы процесса разработкиОтметим, что наиболее трудоемким при разработке ПС является архитектурное и детальное проектирование, в ходе которого ведется разработка основных аспектов программного проекта: − определение архитектуры программной системы как совокупности взаимодействующих компонентов; − создание структуры данных, составляющих информационную базу; − проектирование алгоритмов, отражающих детали поведения при реализации выполняемых процессов; − разработка пользовательского интерфейса; − документирование.2 ЭВОЛЮЦИЯ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ2.1 Особенности разработки сложных программных системИз года в год увеличиваются разнообразие и сложность систем, получивших в международной научно-технической практике название систем, интенсивно использующих программное обеспечение (Software Intensive Systems, SIS). В системах такого рода функциональный потенциал определяется программным обеспечением (ПО) или зависит от ПО в существенной мере. Общепризнанный законодатель в области исследований и разработок SIS институт программной инженерии университета Карнеги-Меллон (Software Engineering Institute, SEI) относит к классу SIS системы, в которых программные системы представляет существенный сегмент по следующим позициям: функциональность системы, ее стоимость, риски в процессе разработки, время разработки. В таких системах программные компоненты взаимодействуют друг с другом и компонентами, и подсистемами другой природы, датчиками, приборами и людьми, вовлеченными в процессы использования SIS. К числу SIS, например, относятся разнородные автоматизированные системы управления, встроенные бортовые транспортные системы, телекоммуникационные и корпоративные системы, в том числе и на базе web-сервисов. Для разработок SIS типичны крупномасштабные проекты ─ десятки или сотни разработчиков, месяцы или годы разработки, сотни тысяч или десятки миллионов долларов, комплексирование из многочисленных разнородных подсистем, большая часть из которых включает программные системы. Такие программные системы называют сложными или «большими», программными комплексами, программными продуктами. Они отличаются от «небольших» не только по размерам (достаточно вспомнить современные операционные системы). Важным для таких систем является наличие дополнительных факторов. Эти факторы связаны с востребованностью программных систем, и готовностью пользователей платить деньги, как за приобретение самой программы, так и за ее сопровождение и даже за специальное обучение работе с ней. Не все программные системы сложны. Существует множество программ, которые задумываются, разрабатываются, сопровождаются и используются одним и тем же человеком. Обычно это начинающий программист или профессионал, работающий изолированно. Нельзя сказать, что все такие системы плохо сделаны или, тем более, усомниться в квалификации их создателей. Но такие системы, как правило, имеют очень ограниченную область применения и короткое время жизни. Обычно их лучше заменить новыми, чем пытаться повторно использовать, переделывать или расширять. Разработка подобных программ скорее утомительна, чем сложна, так что изучение этого процесса нас не интересует.Какого-либо одного формального признака, отличающего обычную программу от сложной, не существует. В целом, сложные программы выгодно отличаются разнообразием предоставляемого сервиса и количеством обрабатываемой информации. Возможно обозначить лишь некоторые качественные характеристики, свойственные сложной программе. Сложная программа характеризуется также более сложным алгоритмом обработки событий. В частности, такая программа, предполагает некоторую реакцию на вмешательство пользователя в управляемый процесс или объект. Существенно, что сложные программы, предназначены для многократного использования и применения разными пользователями. В связи с этим следует обратить внимание на ряд необходимых свойств ПО. Обычно сложная программа обладает следующими свойствами: 1) программа решает одну или несколько связанных прикладных задач, зачастую сначала не имеющих четкой постановки, настолько важных для каких-либо лиц или организаций, что те приобретают значимые выгоды от ее использования; 2) программа не предназначена для решения каких-либо прикладных задач, но от нее зависит эффективное решение этих прикладных задач. Это системные программы, например, операционные системы, системы управления базами данных, различные инструментальные системы и т.п.; 3) существенно, чтобы программа была удобной в использовании. В частности, она должна включать достаточно полную и понятную пользователям документацию, возможно, также специальную документацию для администраторов, а также набор документов для обучения работе с программой; 4) программа должна обладать высокой производительностью, высокой реактивностью или удовлетворять другим требованиям, в противном случае ее использование по назначению (на реальных данных) может привести к значимым для пользователей потерям; 5) программа должна обладать высокой надежностью. Неправильная работа программы может нанести ощутимый ущерб пользователям и другим организациям, и лицам, даже если сбои происходят не слишком часто; 6) для выполнения своих задач программа должна удовлетворять требованиям совместимости, переносимости и интеграции с другими программами и программно-аппаратными системами и обеспечивать работу на разных платформах; 7) пользователи, работающие с программой, могут приобретать дополнительные выгоды от того, что программа развивается, в нее вносятся новые функции и устраняются ошибки. Поэтому необходимо наличие проектной документации, позволяющей развивать ее, возможно, вовсе не тем разработчикам, которые ее создавали, без больших затрат на обратную разработку (реинжиниринг); 8) в разработку программы вовлечено значительное количество людей (десятки и сотни человек). Большую программу практически невозможно написать с первой попытки, с небольшими усилиями и в одиночку; 9) большая программа имеет намного большее количество ее возможных пользователей по сравнению с небольшими программами, и еще больше тех лиц, деятельность которых будет так или иначе затронута ее работой и результатами. Примерами больших программ могут служить операционные системы, системы программирования, системы сетевых протоколов, библиотеки классов Java или C# и т.п. Строго говоря, ни одно из указанных свойств не является обязательным для того, чтобы программу можно было считать большой, но при наличии двух-трех из них достаточно уверенно можно утверждать, что она большая. На основании некоторых из перечисленных свойств можно сделать вывод, что большая программа или программная система чаще всего представляет собой не просто код или исполняемый файл, а включает еще и набор проектной и пользовательской документации. Рост спроса на программные системы (ПС) является следствием того, что по мере удешевления, повышения надежности и увеличения объема производства компьютеров автоматизация труда человека с помощью компьютера становится все более выгодной. Эту тенденцию, отмеченную Б. Боэмом еще в 80-е годы прошлого века и подкрепленную нашим временем, иллюстрирует рисунок 3, на котором показано расширение масштабов использования компьютеров и увеличение социального влияния этого использования. Надо сказать, часто жизнь вносит свои поправки и ожидаемые события опережают время.Рисунок 3 – Тенденция расширения масштабов использования компьютеровВ США к 1985 году примерно 40 % работающих использовали в своей профессиональной деятельности компьютер и программные системы (ряд 1 на рисунке 3), не обязательно зная, как эти средства функционируют. По данным в США в 2010 году уровень использования компьютеров составил 90%, в Европе – 70%. Однако эта тенденция усиливается, и к 2015 году около 95% работающих будут использовать компьютеры в своей повседневной деятельности. При этом более половины пользователей будут иметь определенные знания о работе компьютера. Еще более глубокое воздействие компьютеры и ПС оказывают на частную жизнь. С каждым днем все большая часть данных, относящихся к личной жизни, банковским счетам, коммунальным услугам, медицинскому обслуживанию, управлению движением, воздушному сообщению, общественному питанию, производству материальных ценностей и др., а также национальной безопасности доверяется компьютерам и программным системам. Поэтому все труднее становится ограничивать потенциальную угрозу личному благосостоянию, которая возможна при использовании компьютеров в преступных целях, а также из-за наличия большого числа банков и баз данных, содержащих сведения о всех и обо всем, и вычислительных систем, заставляющих людей думать и действовать как машины. В нашей стране с 1 января 2010 года все организации, обрабатывающие в своих информационных системах персональные данные физических лиц (сотрудников, клиентов, партнеров и т.п.), независимо от размера и формы собственности должны выполнять требования, установленные законом № 152-ФЗ «О персональных данных». Последние изменения по защите персональных данных были внесены федеральным законом № 261-ФЗ от 25.07.2011. Этим законом была уточнена сфера действия Федерального закона «О персональных данных», используемые в нём основные понятия, принципы и условия обработки персональных данных. Все возрастающее воздействие компьютеров на благосостояние человека предъявляет несколько важных требований к созданию программных систем. Эти требования состоят в необходимости такой разработки и сопровождения ПС, которые гарантируют, что вычислительные системы должны быть:– исключительно надежными; – удобными в использовании; – безопасными и труднодоступными для злоупотреблений; – проверяемыми; – оставляющими главную (решающую) роль за человеком, а не компьютером. Основная доля затрат при создании таких вычислительных систем приходится на прикладное программное обеспечение (ПО) и базы данных (БД). Производство ПО является в настоящее время крупнейшей отраслью мировой экономики, в которой заняты миллионы специалистов, непосредственно производящих программный продукт или опосредованно участвующих в этом процессе. Стоимость и качество производимого программного продукта определяется уровнем развития инженерного программирования. Важность инженерного программирования обусловливается двумя основными тенденциями: – программные продукты являются сложными изделиями, и их стоимость все более возрастает; – программное обеспечение оказывает значительное и все возрастающее воздействие на общественно благосостояние и развитие общества.2.2 Проблемы создания программных системПрограммные системы применяются для решения самых разных задач, таких, например, как системы с обратной связью, которые управляют или сами управляются событиями физического мира и для которых ресурсы времени и памяти ограничены; задачи поддержания целостности информации объемом в сотни тысяч записей при параллельном доступе к ней с обновлениями и запросами; системы управления и контроля за реальными процессами (например, диспетчеризация воздушного или железнодорожного транспорта). Системы подобного типа обычно имеют большое время жизни, и большое количество пользователей оказывается в зависимости от их нормального функционирования. В мире промышленных программ мы также встречаем среды разработки, которые упрощают создание приложений в конкретных областях, и программы, которые имитируют определенные стороны человеческого интеллекта. Существенная черта промышленной программы – уровень сложности: один разработчик практически не в состоянии охватить все аспекты такой системы. Грубо говоря, сложность промышленных программ превышает возможности человеческого интеллекта. Увы, но сложность, о которой мы говорим, по-видимому, присуща всем большим программных системам. Говоря «присуща», мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя. Проблемы создания программных систем (ПС) следуют из их свойств и именно из их сложности. Современные крупномасштабные проекты ПС характеризуются следующими особенностями: – структурной сложностью (многоуровневой иерархической структурной организацией) и территориальной распределенностью; – функциональной сложностью (многоуровневой иерархией и большим количеством функций, сложными взаимосвязями между ними); – информационной сложностью, большим количеством источников и потребителей информации, разнообразными формами и форматами представления информации, сложной технологией прохождения документов др.; – большим количеством внешних систем различных организаций с разными форматами обмена информацией; – высокой технической сложностью, определяемой наличием совокупности тесно взаимодействующих подсистем (компонентов), имеющих свои локальные задачи и цели функционирования; – сложной динамикой поведения, обусловленной высокой изменчивостью внешней (изменения в законодательных и нормативных актах, нестабильность экономики и политики) и внутренней среды (структурная реорганизация, текучесть кадров и др.); – отсутствием полных аналогов, ограничивающих возможность использования каких-либо типовых проектных решений и прикладных систем, высокой долей вновь разрабатываемых программ. Дополнительными факторами, увеличивающими сложность разработки программных систем, являются: 1) Сложность реальной предметной области, из которой исходит заказ на разработку. Сложность задачи и порождает сложность программного продукта, Проблемы, которые пытаются решить с помощью программного обеспечения, часто неизбежно содержат сложные элементы, а к соответствующим программам предъявляется множество различных, порой взаимоисключающих требований. Эта внешняя сложность обычно возникает из-за «нестыковки» между пользователями системы и ее разработчиками: пользователи с трудом могут объяснить в форме, понятной разработчикам, что на самом деле нужно сделать. Бывают случаи, когда пользователь лишь смутно представляет, что ему нужно от будущей программной системы. Это в основном происходит не из-за ошибок с той или иной стороны; просто каждая из групп специализируется в своей области, и ей недостает знаний партнера. У пользователей и разработчиков разные взгляды на сущность проблемы, и они делают различные выводы о возможных путях ее решения. 2) Сложность определения требований к программным системам. Во-первых, по причине необходимости учета большого количества различных факторов. Во-вторых, по причине слабого (чаще всего) знания разработчиками предметной области применения ПС. В то же время специалисты в этой предметной области, как правило, не могут сформулировать проблему в нужном для разработчика ракурсе. 3) Отсутствие удовлетворительных средств формального описания поведения дискретных систем. Популярные последнее время средства графического языка UML не решают полностью этой задачи. В процессе создания ПС часто используются языки сравнительно низкого уровня (например, С при разработке операционных систем), что приводит к ранней детализации операций в процессе создания ПС и увеличивает объем описания разрабатываемых продуктов (десятки миллионов строк языка программирования в операционных системах). 4) Коллективная разработка. Вследствие больших объемов ПС разработка ведется достаточно большим коллективом специалистов, иногда сотни и тысячи разработчиков (достаточно напомнить проект OS/360, не говоря уже о линейки современных Windows). Обеспечивать целостность и качество проекта в этом случае трудно по причине сложности организации эффективного взаимодействия специалистов в таких коллективах. 5) Необходимость увеличения степени повторяемости кодов. С целью увеличения производительности труда компании стремятся к созданию библиотек компонентов, которые можно было бы использовать в дальнейших разработках. Однако в этом случае компоненты приходится делать более универсальными, что в итоге увеличивает сложность разработки. Однако не только повторяемость кодов сказывается негативно. Стремление использовать имеющийся задел приводит к «перетягиванию» нелучшего кода в последующие разработки. Здесь можно вспомнить, как Microsoft долго уверяла общественность о ликвидации 16-разрядного DOS-кода (и не только его) в разработке последующих операционных систем. 6) Большая программная система – это крупное капиталовложение, и нельзя позволить выкидывать сделанное при каждом изменении внешних требований. Тем не менее, даже большие системы имеют тенденцию к эволюции в процессе их использования: следовательно, встает задача о том, что часто неправильно называют сопровождением программного обеспечения. Чтобы быть более точными, введем несколько терминов: – под сопровождением понимается устранение ошибок; – под эволюцией – внесение изменений в систему в ответ на изменившиеся требования к ней; – под сохранением – использование всех возможных и невозможных способов для поддержания жизни в дряхлой и распадающейся на части системе. К сожалению, опыт показывает, что существенный процент затрат на разработку программных систем тратится именно на сохранение. Все вместе перечисленные факторы существенно увеличивают сложность разработки программных систем [2].2.3 Инженерный подход к разработке ПСВ начале 70-х годов прошлого века в США заговорили о кризисе в программировании. Он выражался в том, что большие программные проекты стали выполняться с отставанием от графика или с превышением сметных расходов, разработанный программный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемых ПС не устраивало потребителей. Аналитические исследования и обзоры, выполненные в последующие годы ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, результаты исследований, проведенных в 1995 году компанией Standish Group, проанализировавшей работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, показали, что только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции. С опозданием были завершены 52,7% проектов, расходы на их разработку превысили запланированный бюджет, а требуемые функции не были реализованы в полном объеме. Аннулированы до завершения 31,1% проектов. Для двух последних категорий проектов бюджет среднего проекта превышен на 89%, а срок выполнения на 122%. В 1998 году процентное соотношение трех перечисленных категорий лишь немного изменилось в лучшую сторону (26, 46 и 28 % соответственно) и в последующие годы улучшилось незначительно. Причинами столь низких показателей, по мнению разработчиков, являются следующие: – нечеткая и неполная формулировка требований к программным системам; – недостаточное вовлечение пользователей в работу над проектом; отсутствие необходимых ресурсов; – неудовлетворительное планирование и плохое управление проектом; частые изменения требований и спецификаций; – новизна и несовершенство используемой технологии; – недостаточная поддержка со стороны высшего руководства; – недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта. Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привели в конце 70-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО. Начала развиваться совокупность инженерных методов и средств создания программного обеспечения, объединенных общим названием программная инженерия. Впервые этот термин (software engineering) был использован как тема конференции, проведенной под эгидой НАТО в 1968 году. В 1975 году в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии. В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО на основе объектно-ориентированного подхода [1].2.4 Становление и развитие программной инженерииПрограммная инженерия – это область компьютерной науки и технологии, которая занимается построением программных систем, настолько больших и сложных, что для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций. Обычно такие системы существуют и применяются долгие годы, развиваясь от версии к версии, претерпевая на своем жизненном пути множество изменений, улучшение существующих функций, добавление новых или удаление устаревших возможностей, адаптацию для работы в новой среде, устранение дефектов и ошибок. Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств. В основе программной инженерии лежит фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Однако, как показывает опыт более тридцати прошедших лет, использовать математические методы для формализации процесса проектирования программных систем не столь просто, и успехи в этом отношении достаточно скромные. Ф. Брукс, руководитель проекта разработки операционной системы OS/360, отмечал, что самым существенным свойством программных систем является их сложность. По причине уникальности и несхожести своих составных частей программные системы отличаются от технических систем, например, компьютеров, в которых преобладают повторяющиеся элементы. Сами компьютеры сложнее большинства продуктов человеческой деятельности. Количество их возможных состояний очень велико, поэтому их так трудно понимать, описывать и тестировать. У программных систем количество возможных состояний на порядок превышает количество состояний компьютеров. Дополнительно к отмеченным выше особенностям ПО нужно добавить следующие: – сложность описания программной системы, обусловленная большим количеством функций, процессов, элементов данных и сложными взаимосвязями между ними); – наличие, как правило, в программной системе совокупности тесно взаимодействующих подсистем, имеющих локальные задачи и цели функционирования, которые могут быть противоречивыми; – отсутствие полных аналогов, ограничивающее возможность использования типовых проектных решений и прикладных систем при создании новой программной системы; – необходимость интеграции существующих и, вновь разрабатываемых программных систем и приложений; – функционирование сложной программной системы в неоднородной среде на нескольких аппаратных платформах и в различных операционных средах, часто трудно совместимых; – разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;– временная протяженность проекта, обусловленная сложностью проекта, ограниченными возможностями коллектива разработчиков, масштабами организации-заказчика и различной степенью готовности подразделений заказчика к внедрению программной системы. Как уже отмечалось, сложность – существенное свойство программных систем. Многие проблемы разработки следуют из этой сложности и ее нелинейного роста при увеличении размера системы. Сложность является причиной затруднений, возникающих в процессе общения между разработчиками, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию графика работ. Сложность вызывает трудности понимания всех возможных состояний программ, что приводит к снижению их надежности. Сложность структуры сдерживает развитие программной системы и возможность добавления новых функций. Для успешной реализации проекта объект проектирования (ПС) должен быть адекватно описан, т.е. должны быть построены полные и непротиворечивые модели архитектуры ПС, определяющей совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих структурные элементы. По мнению Г. Буча, моделирование – центральное звено всей деятельности по созданию качественного программного обеспечения. Модели строятся, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания, уменьшить возможный риск, а также документировать принимаемые проектные решения. Модель – это полное описание программной системы с определенной точки зрения. Ни одна модель не является абсолютно достаточной. Напротив, чтобы понять большинство систем, кроме самых тривиальных, требуется множество взаимосвязанных моделей. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры. Модели разрабатываются на специальных языках. Язык моделирования должен включать: – элементы модели – функциональные концепции моделирования и их семантику; – нотацию (систему обозначений) – визуальное представление элементов моделирования; – руководство по использованию – правила применения элементов в рамках построения тех или иных типов моделей программных систем. Модели представляют собой абстракции, которые отображают основу сложной проблемы или структурируют ее, скрывая второстепенные детали, и тем самым делают проблему более доступной для понимания. Для создания сложной системы разработчик должен рассмотреть ее с разных точек зрения, построить модель с использованием подходящей для данной предметной области терминологии (нотации), проверить, что модель удовлетворяет требованиям, предъявляемым к системе, и, наконец, построить на основе созданной модели требуемую сложную систему. Уже более 10 лет унифицированный язык моделирования UML (Unified Modeling Language) является промышленным стандартом для визуализации, специфицирования, конструирования и документирования артефактов систем, в которых главная роль принадлежит программному обеспечению. Артефакты являются строительными блоками при моделировании физических аспектов системы. Артефакт – это физическая и заменяемая часть системы. Артефакты используются для моделирования таких физических сущностей, которые могут располагаться на узлах – физических элементах, представляющих вычислительный ресурс, – например, исполняемых программ, библиотек, таблиц, файлов и документов. Будучи де-факто стандартным языком моделирования, UML дает разработчикам возможность достичь взаимопонимания и избежать разночтений. Очевидно, что конечная цель разработки ПС – это не модель, а работающее приложение в форме программного кода. Диаграммы UML, в конечном счете, – лишь наглядные изображения, поэтому используя языки графического моделирования, важно понимать, чем они могут помочь при написании кода программы. Использование графических языков моделирования целесообразно в следующих случаях: – при изучении методов проектирования. Программисты, многие годы, работающие до появления объектно-ориентированной технологии отмечают серьезные трудности, связанные с освоением объектно-ориентированных методов и, в первую очередь, со сменой парадигмы. Графические средства облегчают решение этой проблемы; – при общении с заказчиками программной системы, будущими пользователями и экспертами организации. Графические методы наглядно и понятно представляют архитектуру системы и объясняют, что эта система будет делать; – при получении общего представления о системе. Графические методы показывают, какого рода абстракции существуют в системе и какие ее части нуждаются в дальнейшем уточнении. Эта информация полезна при появлении в коллективе разработчиков новых сотрудников. Следует отметить, что в последней версии UML 2.0 возможности языка были расширены (формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года, последняя версия UML 2.3 опубликована в мае 2010 года). Благодаря свой выразительности он позволяет моделировать буквально все – от офисных информационных систем и распределенных Web-приложений до встроенных систем реального времени. Язык UML – нечто большее, чем просто набор графических символов. Каждый из этих символов имеет четкую семантику. Это означает, что один разработчик может описать модель на языке UML, а другой разработчик и даже инструментальное средство – однозначно интерпретировать ее. Язык UML – это язык специфицирования, он позволяет специфицировать все важные решения, касающиеся анализ, дизайна и реализации, принимаемые в процессе разработки и внедрения программных систем. UML не является языком визуального программирования, но его модели могут быть непосредственно ассоциированы с такими языками программирования, как Java, C++, C# или Visual Basic. Отображение модели на язык программирования позволяет осуществить прямое проектирование – генерацию кода из модели, обратное проектирование (восстановление модели по коду) также возможно. Многие компании, специализирующиеся на разработке программных продуктов, помимо исполняемого кода производят и другие продукты. Сюда относится все, что связано с разработкой требований, архитектурой, проектными решениями (дизайном), исходным кодом, проектными планами, тестами, прототипами, релизами (версиями) и др. Корпорация IBM – крупнейшая в мире компания, работающая в области информационных технологий, – лидер в разработке и внедрении инновационных решений, предлагает полный комплекс решений, сетевых технологий и услуг, которые помогают преобразовать традиционные процессы в компаниях-разработчиках программного обеспечения и максимально эффективно использовать их интеллектуальные ресурсы и новые рыночные возможности. В 2003 году в состав компании IBM вошла корпорация Rational Software. Платформа Rational вместе с Lotus, Tivoli, WebSphere и DB2 вошла в число ключевых компонентов стратегии IBM по созданию программного обеспечения. IBM Rational выпускает CASEсредства, системы автоматизированного проектирования ПО, а также средства управления проектами, связанными с разработкой, документированием и сопровождением крупных информационных систем [5].

ЗАКЛЮЧЕНИЕ

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1) Боэм, Б. У. Инженерное проектирование программного обеспечения / Б. У. Боэм. – М.: Радио и связь. – 1985. – 512 с.2) Брауде, Эрик Дж. Технология разработки программного обеспечения / Эрик Дж. Брауде. – СПб.: Питер, 2004. – 655 с.3) Гвоздева, Т. В. Проектирование информационных систем: учеб. пособие / Т. В. Гвоздева, Б. А. Баллод. – Ростов н/Д: Феникс, 2009. – 508 с.4) Орлов, С. А. Технологии разработки программного обеспечения / С. А. Орлов, Б. Я. Цилькер. – СПб.: Питер, 2012. – 608 с.5) Тарасенко, Ф. Л. Прикладной системный анализ: учеб. пособие / Ф. Л. Тарасенко. – М.: КНОРУС, 2010. – 224 с.