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

1. Проектирование и архитектуры программных систем Лектор : доктор технических наук, профессор Назаров С.В. s_nazarov@mail.ru, каб. 827, каф. Архитектуры ПС

2. Проектирование архитектуры программных систем Тематический расчет часов

3. Структура учебных тем

4. Литература Базовый учебник 1. Крылов Е.В. Техника разработки программ.: В 2 кн. Кн. 2 Технология, надежность и качество программного обеспечения: Учебник / Е.В. Крылов, В.А. Островский, Н.Г. Типикин. – М.: Высш. Шк., 2008 Основная 2. Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения: учебное пособие / под ред. Л.Г. Гагариной. – М.: ИД «Форум»: Инфра-М, 2008 3. Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. 2-е издание. – СПб.: Питер, 2006 4. Полис Г., Огастин Л., Мадхар Д. Разработка программных проектов: на основе Rational Unified Process (RUP). – М.: ООО «Бином-Пресс», 2009 5. Боггс У., Боггс М. UML и Rational Rose. «Лори», 2008 6. Кватрани Т., Палистрант Д. Визуальное моделирование с помощью IBM Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-ПРЕСС. – 2007 7. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с анг. – М.: ДМК Пресс, 2007. 8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. Учебник для вузов. 2-е изд. – М.: Финансы и статистика, 2006

5. Дополнительная 9. Кериевски Д. Рефакторинг с использованием шаблонов.: Пер. с англ. – М.: ООО «И.Д. Вильямс»,2008 10. Назаров С. В. Операционные системы специализированных вычислительных комплексов: Теория построения и системного проектирования. - М.: Машиностроение, 1989. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. – М.: Радио и связь. 1985. – 512 с. Жоголев Е.А.. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994. Зиглер К.. Методы проектирования программных систем: Пер. с англ. – М .: Мир, 1985. – 328 с. Колин Ю. Применение Rational Software Architect в разработке, управляемой моделями: Часть 1. Обзор парадигмы разработок, управляемых моделями с шаблонами. http://www.ibm.com/developerworks/ru/library/1121_yu/index.html?S_TACT=105AGX63&S_CMP=NWLTR&ca=dnn-rut2405 Колин Ю. Применение Rational Software Architect в разработке, управляемой моделями и на основе шаблонов: Часть 2. Инструментальная поддержка разработки. http://www.ibm.com/developerworks/ru/library/0116_yu/#author1 Калямин В.В. Технологии программирования. Компонентный подход. Учебное пособие. ИНТУИТ.РУ, Бином. Лаборатория знаний, 2010 Майерс Г. Надежность программного обеспечения: Пер. с англ. – М .: Мир, 1980. – 360 с.

6. Структура итоговой оценки по учебной дисциплине:

7. Тема 1. Введение. Проблемы создания программных систем 1.1. Особенности разработки больших программных систем 1.2. Программные системы (ПС) как отрасль экономики 1.3. Проблемы создания ПС 1.4. Кризис программирования 1.5. Становление и развитие программной инженерии 1.6. Развитие технологий программирования Литература: Л1 с. 4 – 14; Л2 с. 5 – 32; Вендров А.М. Проектирование программного обеспечения. – М.: Финансы и статистика, 2000. с. 7 – 14, 322 - 335

8. 1.1. Особенности разработки больших программных систем Сложные или “большие” программы (ПС) отличаются от “небольших” не столько по размерам сколько наличием дополнительных факторов. Эти факторы связаны с их востребованностью и готовностью пользователей платить деньги, как за приобретение программы, так и за ее сопровождение и даже за специальное обучение работе с ней. Обычно сложная программа обладает следующими свойствами: 1) программа решает одну или несколько связанных задач, зачастую сначала не имеющих четкой постановки, настолько важных для каких-либо лиц или организаций, что те приобретают значимые выгоды от ее использования; 2) существенно, чтобы программа была удобной в использовании. В частности, она должна включать достаточно полную и понятную пользователям документацию, специальную документацию для администраторов, а также набор документов для обучения работе с программой; 3) низкая производительность программы на реальных данных приводит к значимым потерям для пользователей; 4) неправильная работа программы наносит ощутимый ущерб пользователям и другим организациям и лицам, даже если сбои происходят не слишком часто; 5) для выполнения своих задач программа должна взаимодействовать с другими программами и программно-аппаратными системами и обеспечивать работу на разных платформах;

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

10. 1. 2. Программные системы (ПС) как отрасль экономики 1 – пользователи ЭВМ; 2 – пользователи, обязанные иметь представление о работе ЭВМ 2 1 Рост спроса на программные системы и возрастающее воздействие компьютеров на благосостояние человека предъявляет ряд требований к инженерному программированию в части разработки и сопровождения ПС: исключительная надежность, удобство в использовании, труднодоступность для злоупотреблений, проверяемость, главенствующая роль человека, а не компьютера.

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

12. В 1997 г. на сегмент пакетов компьютерных программ и проектных услуг приходится более 30 % мирового рынка информационных технологий. Доходы компаний, действующих на этом рынке составили в 1998 г. 257 миллиардов долларов США. В сфере производства компьютерных программ и проектных услуг в России было занято 8 тыс. человек, в США – 600 тыс. человек. Общий уровень производительности труда в этом секторе составляет 38 % от уровня США (13 % в производстве ПП и 72 % в сегменте проектных услуг). Российские компании в этом секторе в 100 раз меньше американских. Общий сдерживающий фактор –низкий уровень добавленной стоимости выпускаемых программ и услуг, недостаточный спрос со стороны высокоэффективных компаний-клиентов, высокий уровень пиратства (в Росси более90 %). Для российских банков ключевое значение имеет не оптимизация затрат или качество обслуживания, а отношения с органами власти.

13. Сегменты компьютерных программ и проектных услуг близки друг к другу по своим размерам и могут быть разбиты на ряд подсегментов. Компании, работающие в сегменте ПКП производят программы, готовые для продажи или аренды. В 1998 г. совокупные доходы этих компаний составили 133 миллиарда $ США. Доминирующую роль играют компании США (75 % рынка). Российская отрасль ПО очень молода. Фирмам, являющимся ветеранами этого сектора, всего 7 – 8 лет (на 1997 г.).Факторы, способствующие становлению отрасли в конце 80-х – начале 90-х годов: 1. Сокращение военных расходов после распада СССР , что привело к высвобождению и появлению на рынке большого числа специалистов в области ИТ. 2. Формирование новых основ правил, разрешающих частную предпринимательскую деятельность. 3. Большое количество выпускников в области математики, физики, электронике, которые стали профессионалами первой волны в формирующейся отрасли программных продуктов и услуг. 4. Динамичное развитие информационных технологий во всем мире.

15. В развитых странах индустрия программного обеспечения имеет весьма ощутимую долю в структуре ВВП. Например, в США в 2006 году среднегодовой доход от продажи игр принес более 3,8 млрд. долл., а развлекательного ПО в целом — 7,4 млрд. Корпоративные решения и индустрия ПО в целом – доход более 100 млрд. долл. Преимущества развития отрасли ПО для любой страны – неистощимость ее ресурсов (в отличие от добывающего комплекса), экологически чистая отрасль. Отсюда понятно стремление развитых стран занять свое место на глобальном рынке ПО. Совокупный объем ИТ-рынка, согласно EITO, в 2007 г. оценивался в 978 млрд. евро. Сегмент ПО развивался быстрее сегментов ИТ-услуг и аппаратных средств и с опережающими рынок темпами, составившими, по предварительным данным EITO, порядка 7,4% . Однако темпы роста рынка ПО в разных регионах различны: в развитых странах они ниже, например в странах Западной Европы темпы не превысили 6,5%, а в Японии даже 3,9%, в то время как в развивающихся странах рынок рос с опережением и темпы роста там оценивались примерно в 9,8%.

16. Совокупный объем рынка программного обеспечения в 2006 году, по данным IDC, равнялся 230,4 млрд. долл., из которых 121,4 млрд. пришлось на США и страны Латинской Америки, 76,2 млрд. — на регион EMEA и 32,8 млрд. — на страны Азиатско-Тихоокеанского региона. Согласно ожиданиям аналитиков, в прошедшем году рынок приблизился к 250 млрд. долл., а в 2011-м, ежегодно подрастая на 7,7%, должен превысить 330 млрд. А Доля ПО в общем объеме ИТ-рынка зависит от степени его зрелости: в развитых странах она больше и составляет от 22 до 25% всех расходов на информационные технологии. Например, в Западной Европе и США на приобретение ПО уходит более четверти всех ИТ-расходов. В целом по миру на долю ПО приходится примерно пятая часть всех ИТ-затрат (по данным IDC на 2006 год — 21%).

17. Российский рынок ИТ относится к числу наиболее быстро развивающихся в мире. В 2007 году, согласно последнему отчету аналитического центра REAL-IT Лиги независимых экспертов в области ИТ (ЛИНЭКС), он вырос на 15,3%. Однако темпы его роста все же вновь снизились: в 2006 году рынок подрос на 19,7%, в 2005-м — на 27%, а в 2001-м — даже на 60,6%. Совокупный объем ИТ-рынка, по предварительным данным, составил порядка 15,96 млрд. долл. Общее снижение темпов роста по рынку не сказалось на темпах роста в сегменте ПО. В 2007 году темпы роста сегмента ПО перестали падать, начали расти и составили 22,7% , в то время как в 2006-м они не превысили 17,5%. Специалисты объясняют изменение направление тренда сменой импульсов — полностью исчерпавшего себя «дефицитного импульса» на «рыночный импульс». Суть его в том, что в России начинают появляться новые сферы бизнеса, в которых ИТ превращаются в инструмент повышения конкурентоспособности. Согласно прогнозам, такая положительная динамика сохранится, в результате чего темпы роста на российском рынке ПО могут достичь 23,5%.

18. В России доля ПО в общем объеме ИТ-рынка на 2007 год оценивалась в 11,7%. На долю ПО в России средств затрачивается даже меньше, чем в среднем по Восточной Европе. По уровню зрелости российский ИТ-рынок остается самым незрелым из европейских. Однако доля ПО в 2007 году оказалась на 0,7% больше, чем в 2006-м, а доля средств, затрачиваемых на приобретение аппаратного оборудования, продолжает сокращаться, что свидетельствует о положительных сдвигах в данном сегменте экономики. Вместе с тем пока на приобретение оборудования в России затрачивается более 64% ИТ-средств (то есть в 5,5 раза больше, чем на покупку ПО), в то время как в странах со зрелым ИТ-рынком объемы рынков ПО и аппаратных средств сопоставимы. Согласно REAL-IT, общий объем российского рынка ПО в 2007 году оценивался всего в 1,87 млрд. долл., а доля российских разработок в глобальном объеме рынка программного обеспечения по-прежнему оставалась менее 1%, что невероятно мало. И это при том, что у России изначально имелись и сейчас есть неплохие шансы занять свою нишу на мировом рынке ПО.

19. Этому способствуют высокие темпы роста российского рынка ПО, возрастающая инвестиционная привлекательность российской экономики (объем прямых инвестиций в экономику ежегодно увеличивается в 2 раза и более) и впечатляющий научный и кадровый потенциал. Однако реализация этих возможностей сдерживается проблемами отрасли и несогласованностью программ государственной поддержки. Основными проблемами сегодня остаются высокая фрагментация отрасли, сложность доступа на международные рынки, отсутствие эффективной системы коммерциализации технологий и недостаток квалифицированных управленцев. С точки зрения же самих участников рынка, отраженной в отчете НП «РУССОФТ», успешному развитию отрасли препятствуют действующая система налогообложения, бюрократические и административные барьеры, а также отсутствие государственной поддержки в базовых направлениях — в международной маркетинговой деятельности и сертификации по международным стандартам.

20. 1.3.Проблемы создания ПС следуют из их свойств: 1)структурная сложность(многоуровневая иерархическая структурная организация) и территориальная распределенность; 2) функциональная сложность (многоуровневая иерархия и большое количество функций, сложная взаимосвязь между ними); 3) информационная сложность, большое количество источников и потребителей информации, разнообразные формы и форматы представления информации, сложная технология прохождения документов; 4) большое количество внешних взаимодействующих устройств различных организаций с разными форматами обмена данными; 5) высокая техническая сложность, определяемая совокупностью тесно взаимодействующих подсистем (компонентов), имеющих свои локальные задачи и цели функционирования; 6) сложная динамика поведения, обусловленная высокой изменчивостью внешней (изменения в законодательных и нормативных актах, нестабильность экономики и политики) и внутренней среды (структурные реорганизации, текучесть кадров и т. п.); 7) отсутствие полных аналогов, ограничивающих возможность использования каких-либо типовых проектных решений и прикладных систем, высокая доля вновь разрабатываемых программ.

21. Дополнительные факторы, увеличивающие сложность разработки программных систем: 1. Сложность определения требований к программным системам. Во-первых, по причине необходимости учета большого количества различных факторов. Во-вторых, по причине слабого (чаще всего) знания разработчиками предметной области применения ПС, а специалисты в этой предметной области, как правило, не могут сформулировать проблему в нужном ракурсе. 2. Отсутствие удовлетворительных средств формального описания поведения дискретных систем. В процессе создания ПС используются языки сравнительно низкого уровня, что приводит к ранней детализации операций в процессе создания ПС и увеличивает объем описания разрабатываемых продуктов (десятки миллионов строк ЯВУ. 3. Коллективная разработка. Вследствие больших объемов ПС разработка ведется большим коллективом специалистов. Обеспечивать целостность проекта в этом случае трудно по причине сложности организации эффективного взаимодействия специалистов даже в сравнительно небольших коллективах. 4. Необходимость увеличения степени повторяемости кодов. С целью увеличения производительности труда компании стремятся к созданию библиотек компонентов, которые можно было бы использовать в дальнейшем. Однако в этом случае компоненты приходится делать более универсальными, что в итоге увеличивает сложность разработки.

22. 1.4. Кризис программирования Суть проявления кризиса (70-е гг. ХХ века): 1. Большие программные проекты выполняются с отставанием от запланированного графика. 2. Проекты превышают сметные расходы. 3. Разработанный программный продукт не обладает требуемыми функциональными возможностями. 4. Производительность программных систем недостаточна. 5. Качество программного продукта не удовлетворяет пользователей. Результаты исследований компании Standish Group (1995 г.) по работе 364 американских корпораций и выполнению более 23000 проектов: - только 16,2 % проектов завершились в срок,не превысили запланированный бюджет и реализовали все требуемые функции; - с опозданием были завершены 52,7 % проектов, расходы на их разработку превысили запланированный бюджет, а требуемые функции не были реализованы в полном объеме; - аннулированы до завершения 31,1 % проектов; - для двух последних категорий проектов бюджет среднего проекта превышен на 89 %, а срок выполнения на 122 %; - в 1998 г. процентное соотношение трех перечисленных категорий лишь немного изменилось в лучшую сторону (26, 46 и 28 % соответственно).

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

24. 1.5. Становление и развитие программной инженерии 1-й этап: систематизация и стандартизация процессов создания программных систем на основе структурного подхода. 2-й этап: переход к сборочному индустриальному способу создания программных систем на основе объектно-ориентированного подхода. В основе программной инженерии лежит фундаментальная идея: проектирование ПС является формальным процессом, который можно изучать и совершенствовать. Самое существенное свойство ПС – сложность (Ф. Брукс). Компьютерные системы – самый сложный продукт человеческой деятельности, сложность ПС еще выше из-за громадного числа возможных состояний. сложность Нелинейный рост сложности при увеличении размера системы, затруднения в общении разработчиков проекта, ошибки в продукте, превышение стоимости разработки, затягивание графика работ, трудности в развитии и добавлении новых функций

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

26. Моделирование – центральное звено всей деятельности по созданию качественного ПО (Г. Буч). Модели строятся, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания, уменьшить возможный риск, а также документировать принимаемые проектные решения. Модель – это полное описание программной системы с определенной точки зрения. Хорошие модели являются основой для взаимодействия участников проекта и гарантируют корректность архитектуры. (Важно понимать модель – это не конечный продукт!!). Язык моделирования должен включать: элементы модели – фундаментальные концепции моделирования и их семантику; нотацию (систему обозначений) –визуальное представление элементов моделирования; руководство по их использованию – правила применения элементов в рамках построения тех или иных типов моделей ПС. Использование графических языков моделирования целесообразно в следующих случаях: 1) при изучении методов проектирования (многие отмечают серьезные трудности, связанные с освоением объектно-ориентированных методов и в первую очередь со сменой парадигмы); 2) при общении с экспертами организации-заказчика; 3) при получении общего представления о системе. Графические модели показывают, какого рода абстракции существуют в системе и какие ее части нуждаются в дальнейшем уточнении. К концу 80-х годов появились программно-технологические средства специального класса – CASE-технология создания и сопровождения программных систем.

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

28. Основная Программа Глобальные данные Локальные данные В развитии технологий создания программных систем можно выделить 4 этапа. 1. Первый этап – стихийное программирование. Охватывает период от появления первых ЭВМ до середины 60-х годов ХХ века. В это период отсутствовали сформулированные технологии программирование фактически было искусством. Первые программы имели простейшую структуру и состояли из программы на машинном языке и данных.. Основные вехи этапа: двоичный код, восьмеричный код, 16-ричный код, ассемблеры, макроассемблеры, алгоритмические языки (Фортран, Алгол), подпрограммы, пользовательские функции, процедуры, библиотеки расчетных и служебных подпрограмм. Программа 1 Данные Ассемблер, ЯВУ 3 Программа Глобальные данные 2 Данные Локальные данные Подпрограммы Подпрограммыс локальными данными

29. Основная Программа Глобальные данные Модуль 4 Модуль 2 Модуль 3 Модуль 1 Данные Данные Данные Данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные 2. Второй этап – структурный подход к программированию.В основе структурного подхода лежит декомпозиция (разбиение на части) сложных программ с последующей их реализацией в виде небольших (40 – 50 операторов) подпрограмм. В отличие от используемого ранее процедурного подхода к декомпозиции, структурный подход требовал представления задачи в виде иерархии подзадач простейшей структуры. Проектирование осуществлялось сверху- вниз и подразумевало реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм. Одновременно вводились ограничения на конструкции алгоритмов, рекомендовались формальные модели их описания, а также специальный метод проектирования алгоритмов – метод пошаговой детализации. Подпрограммы Модуль 1 Подпрограммы Данные Подпрограммы Подпрограммы Подпрограммы

30. Поддержка принципов структурного программирования была заложена в основу процедурных языков программирования(PL/1, ALGOL-68, Pascal, C). Они включали основные структурные операторы передачи управления, обеспечивали поддержку вложенных подпрограмм, локализацию и ограничение области видимости данных. Дальнейший рост сложности и размеров ПС потребовал развития структурирования данных. В языках программирования появляется возможность определения пользовательских типов данных. Усиливалось стремление разграничить доступ к глобальным данным программы, чтобы уменьшить количество ошибок при работе с ними. В результате появилась и стала развиваться технология модульного программирования. Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули. Связи между модулями осуществляются через специальный интерфейс, в то время как доступ к реализации модуля запрещен. Практика показала, что структурный подход в сочетании с модульным программированием позволяет получать надежные программы, размер которых не превышает 100 000 операторов. 3. Третий этап – объектный подход к программированию. Объектно-ориентированное программирование определяется как технология создания сложного программного продукта, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследова-нием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений. Впервые объектная структура была реализована в языке имитационного моделирования Simula (60-е годы). Основное достоинство ООП – более естественная декомпозиция программной системы, которая существенно облегчает разработку системы.

31. Модуль 1 Модуль 1 Модуль 1 Модуль 1 Данные Данные Данные Данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные Локальные данные СООБЩЕНИЯ СООБЩЕНИЯ

32. 3. Четвертый этап – компонентный подход и CASE - технологии.Компонентный подход предполагает построение программной системы из отдельных компонентов, физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собирать в динамически собираемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. (В Интернете представлена масса компонентов). Это позволяет программистам создавать продукты, хотя бы частично состоящие из повторно использованных частей, т.е. использовать технологию, хорошо зарекомендовавшую себя в области проектирования аппаратуры. Компонентный подход лежит в основе технологий, разработанных на базеCOM (Component Object Model – компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture – общая архитектура с посредником обработки запросов объектов). Эти технологии используют общие принципы. Технология COMопределяет общую парадигму взаимодействия программ любых типов: приложений, библиотек, операционной системы, т.е. позволяет одной части ПО использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах, на одном компьютере или на разных компьютерах.Модификация COM, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM – распределенная COM). На базе COM и DCOM разработаны компонентные технологии, решающие различные задачи разработки программного обеспечения. 1. OLE-automation– технология создания программируемых приложений, обеспечивающая программируемый доступ к внутренним службам этих приложений. Вводит понятие дисинтерфейса (disinterface) – специального интерфейса, облегчающего вызов функций объекта. Эту технологию поддерживает, например, MS Excel, предоставляя другим приложениям свои службы.

33. 2. ActiveX – технология, построенная на базе OLE-automation, предназначена для создания программного обеспечения как сосредоточенного на одном компьютере, так и распределенного в сети. Предполагает использование визуального программирования для создания компонентов – элементов управления ActiveX. Полученные таким образом элементы управления можно устанавливать на компьютер дистанционно с удаленного сервера, причем устанавливаемый код зависит от операционной системы. Это позволяет применять элементы управления ActiveX в клиентских приложениях Интернета. 3. MTS (Microsoft Transaction Server – сервер управления транзакциями) – технология, обеспечивающая безопасность и стабильную работу распределенных приложений при больших объемах передаваемых данных. 4. MIDAS (Multitier Distributed Application Server – сервер многозвенных распределенных приложений) - технология, организующая доступ к данным разных компьютеров с учетом балансировки нагрузки сети. Технология CORBA, разработанная группой компаний OMC (Object Management – группа внедрения объектной технологии программирования), реализует подход, аналогичный COM, на базе объектов и интерфейсов CORBA. Программное ядро CORBA реализовано для всех основных аппаратных и программных платформ, поэтому эту технологию можно использовать для создания распределенного ПО в гетерогенной вычислительной среде. Отличительная особенность современной технологии программирования – создание и внедрение средств автоматизированной разработки и сопровождения программного обеспечения, которые были названы CASE-технологиями (Computer Aided Software/System Engineering – разработка программного обеспечения программных систем с использованием компьютерной поддержки). Сегодня существуют CASE-технологии ,поддерживающие как структурный, так и объектный (в том числеи компонентный) подходы к программированию.

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

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

37. Программные технологии полезны, если они широко используются. Однако любая конкретная технология в одних отраслях начинает завоевывать популярность быстрее, чем в других. Хороший тому пример – долгая и трудная дорога к пользователям, которую прошли полезные пакеты инструментов для генерации кода и инженерии программного обеспечения. Когда эти пакеты появились вместе с технологией, они еще не были готовы для повсеместного применения, а позже не был готов рынок. Ниже показан этот эффект на примере обеспечения безопасности информации. Безопасность впервые была признана ключевой технологией в ИТ-инфраструктурах в конце 1980-х годов, когда вирус Jerusalem и червь Morris, по-существу, парализовали Internet-трафик . Инциденты продолжались в 1990-х годах, поскольку технология применялась только как особая мера и без тщательного архитектурного анализа. Сейчас, по прошествии двадцати лет, вместе с новыми ИТ-продуктами наконец стали реализовывать базовые принципы обеспечения безопасности. То же самое повторяется в отрасли телекоммуникаций – как показывают атаки в сфере IP-телефонии, здесь опять пока лишь создаются заплатки на особый случай, но без реального контроля. Промышленная автоматизация и другие предметные области еще больше отстают с внедрением инженерии обеспечения безопасности, как это продемонстрировал червь Slammer. (За считанные минуты 27 января 2003 года червь (376 байт), использующий уязвимость в СУБД Microsoft SQL Server 2000, наводнил интернет и смог создать в каналах передачи данных настоящие пробки, поскольку после заражения компьютера он начинает рассылать свой код по случайным IP-адресам в бесконечном цикле)

38. Семинар на тему: Сравнительный анализ технологий программирования 1. “Стихийное” программирование 2. Структурное программирование. 3. Модульное программирование 4. Объектно-ориентированное программирование 5. Компонентное программирование 6. Средства автоматизации программирования Содержание выступлений: 1. Достоинства и недостатки 2. Максимальный размер программного продукта 3. Производительность труда, возможности групповой работы 4. Качество программного продукта 5. Надежность программного продукта 6. Возможности модификации 7. Удобство сопровождения 8. Возможности переноса на другие платформы