Окр ТРПП (Зачёт). 1. История развития технологии программирования (ТП)
 Скачать 122.5 Kb.
|
|
1.История развития технологии программирования (ТП) 1) 50-е года Мощность компьютеров не велика, программирование ведется в машинном коде, в основном решаются научно-технические задачи не высокого уровня с достаточно точной целью. Зарождается модульное программирование (модули, функции, процедуры) появляются первые языки программирования высокого уровня. 2) 60-е годы Число языков программирования значительно увеличиваются. Повышается мощность компьютеров, решаются задачи более сложного уровня. Применяется коллективная разработка технологических задач. 3) 70-е годы Широкое распространение ИС и БД Началось развитие ТП в след. направлениях: - обоснование и широкое внедрение нисходящей разработки и структурного программирования; - развитие абстрактных типов данных и модульного программирования; - исследование проблем обеспечения надежности и мобильности ПС; - создание методики управления коллективной разработки ПС; - появление инструментальных программных средств поддержки ТП 4) 80-е годы - широкое внедрение ПК во все сферы человеческой деятельности; - появление языков программирования учитывающие требования ТП; - развиваются методы и языки спецификаций ПС; - начинается интенсивный процесс стандартизации тех. процессов; - развиваются концепции компьютерных сетей 5) 90-е годы Охват общества интернетом (-)Проблемы защиты программных средств, ПК и ПС. Широкое развитие получили Case средства; начался этап полной информатизации и компьютеризации общества. 6) 2000-е годы Расширение всех сфер деятельности. Новые и мощные.??? Технология программирования- (ТП) система методов, способов и приемов разработки и отладки программ т.е ТП понимаем, как технологию разработки программных средств включая в нее процессы, начиная с момента зарождения идеи, до ее эксплуатации. 2.Модели жизненного цикла ПП Выделяют 5 основных подходов к организации процесса создания и использования ПП 1) Водопадный подход (Разработка ПП состоит из цепочки этапов, на каждом этапе создаются документы используемые на след. этапе) 2) Исследовательское программирование (подход предполагает быструю реализацию рабочих версий программ выполняющих требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей.) Подход- применяется для разработки систем искусственного интеллекта. 3. Прототипирование. (Моделирует начальную фазу исследовательского программирования до создания рабочих версий программ Разработка ПП по установленным требованиям в рамках другого подхода.) 4.Формальное преобразование (Включает разработку формальных спецификации ПП; На этом подходе базируется Case технология) 5. Сборочное программирование (Предполагает, что ПП(ПС) конструируется из компонент, к-рые уже существуют, они хранятся в библиотеке, каждая из которых может многократно использоваться в ПП. Процесс разработки состоит из сборки программ из компонент, а не из программирования.) 3.Документирование ПС. Документацию делят на 2е группы: 1) Документы управления разработкой ПС: ДУРПС (software process documentation) Управляют и протоколируют процессы разработки и сопровождения ПС обеспечивая связи внутри коллектива разработчиков Пси менеджерами ПС – лицами управляющими разработкой ПС. Эти документы могут быть следующих типов: 1)) Планы, оценки и расписания (создаются для прогнозирования и управления процессами разработки и сопровождения ПС) 2)) Отчеты об использовании ресурсов в процессе разработки. 3)) Стандарты (предписывают разработчикам каким принципам, правилам или соглашениям необходимо следовать в процессе разработки). Стандарты могут быть международными, национальными и спец. созданные в рамках одного предприятия. 4)) Рабочие документы (Технические док-ты обеспечивающие связь между разработчиками) 5))Заметки и переписка это документы фиксируют различные детали взаимодействие между менеджерами и разработчиками. 2) Документы входящие в состав ПС. ДВСПС (software product documentation). Описывают программы ПС как с точками зрения их применения пользователями и с точки зрения их разработчиков и сопроводителей. Документы используются на стадии разработки и эксплуатации, эти документы образуют два комплекта с разными назначениями: 1)) Пользовательская документация ПС (П-документация) П-документация (user documentation) объясняет пользователям как они должны действовать, чтобы применить, разрабатываемое ПС. К такой док-ции относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС, при применении ПС для решения своих задач и при управлении ПС. Два вида: 1))) Ординарный пользователь ПС (end user). Используют ПС для решения своих задач в своей предметной области. Пример: инженер – разрабатывающий тех. устройство. Кассир продающая Ж/Д, авиа-билеты. 2))) Администратор ПС (System administrator) Управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС не связанное с модификацией программы. Пример: Он может регулировать права доступа к ПС, поддерживать ПС в рабочем состоянии и т.д. Состав П-документации зависит от аудитории пользователей на которые ориентировано разрабатываемое ПС и от режима использования док-ов. Под аудиторией понимают контингент пользователей ПС у которого есть необходимость в определенной документации ПС. Под режимом использования док-та понимается способ определяющий, каким образом используется этот документ. (Какие-то изменения вносимые в документацию). В состав П-документации входят: а) Общее функциональное описание ПС даёт краткую хар-ку функциональных возможностей ПС. б) Руководство по инсталляции ПС. Предназначена для инсталляции ПС. в) Инструкция по применению ПС. Предназначена для end user. Содержит необходимую информацию по применению ПС организованную в форме удобной для изучения. г) Справочник по применению ПС. Предназначен для end user. Представляется в форме удобной для избирательного поиска отдельных эл-ов. д) Руководство по управлению ПС. Предназначена для администраторов. Разработка П-док-ции начинается сразу после создания внешнего описания, она должна быть простой и удобной. 2)) С-документация (systemdocumentation) Описывает ПС с точки зрения её разработки. Эта док-ция необходима, если ПС предполагает изучение того, как оно устроено и модернизацию его программ. Сопровождение – это продолжающаяся разработка. Две группы С-документации: 1) Документация определяющая строение программ и структур данных ПС и технологию их разработки. Содержит итоговые документы каждого технологического этапа разработки ПС и включает след-цие док-ты. 1)) Внешнее описание ПС. 2)) Описание архитектуры ПС, включая спецификацию каждой эл. подсистемы. 3)) Для каждой программы ПС – описание модульной структуры включая внешнюю спецификацию каждого включенного в нее модуля. 4)) Для каждого модуля описания его строения. 5)) Тесты модулей на выбранном языке программирования. 6)) Док-ты установления достоверности ПС (как входных данных, так и каждой подпрограммой ПС). 2) Док-ция помогающая вносить изменения в ПС. 5. Спецификация качества программных средств. Разработка спецификации качества сводится к построению своеобразной модели качества требуемого ПС,в этой модели должен быть перечень элементарных свойств которые необходимо обеспечить в требуемой ПС и которые в совокупности образуют приемлемое качество ПС для пользователя. Набор элементарных свойств называется примитивами качества ПС. Перечень свойств: 1.Функциональность (это завершонность) 2.Надежность (это завершенность,точность,учтойчивость и защищенность) 3.Легкость применения (это П-документированность,информативность,коммуникабельность, защ. и устойчивость) 4.Эффективность (эффективность по ресурсам,по памяти,по устройствам) 5.Сопровождаемость (изучаемость-характеристики ПС,которые позволяют минимизировать усилия по изучению к пониманию программ и документации ПС.модифицируемость -характеристики ПС,которые позволяют автоматически настраивать на условия применения Пс или упращают внесение в него вручную изменений или доработок) 6.Изучаемость (это С-документирование,информативность,понятность,структурированость,удобочитаемость) 7.Модифицируемость (расширяемость (внесение доработок) структурируемость, модульность(все разбить на модули)) 8.Мобильность (независимость от устройства, структурированность и модульность) 9.Завершенность(это свойство характеризующее степень отладки пс всеми необходимыми частями и свойствами требующимися для выполнения функций) 10.Точность(эта мера характеризирующая приемлемость велечины погрешности в результатах) 11.Автономность(способность ПС выполнять функции без помощи или поддержки других компонентов ПО) 12.Устойчивость (Способность ПС продолжать корректное функционирование не смотря на задание ошибочных входных данных) 13.Защищенность (противостоять преднамеренным или нечаянным разрушающим действиям пользователя.) 14.П-документированность(характеризующее наличие,полнату, доступность и наглядность учебный, инструктивный, справочной документации) 15.Информативность(характеризуещее наличие в составе ПС информации необходимой и достаточной для понимания назначения ПС,ограничений,входных данных и результатов , а так же текущего состояния программ в процессе их функционирования) 16.Коммуникабельность(это свойство характеризующее степень в которой ПС облегчает задание или описание входных данных и способность выдавать полезные сведения в простой форме) 17.Временная эффективность(способность ПС выполнять возложенные на него функции в течении опеределенного отрезка времени) 18.Эффективность по ресурсам (способность ПС выполнять возложенные на него функции при определенных ограничениях на ресурсы.) 19.Эффективность по устройствам (экономичность использования ПК) 20.С-документированность (наличие документов или документации отражающие требования к ПС и результаты различных этапов разработки ПС включающие возможности ограничения,обоснования ПС) 21.Понятность(степень в которой ПС позволяет человеку понять его назначение,допущения,ограничение) 22.Структурированность(ПС с точки зрения организации взаимосвязанных частей в единое целое определенным образом) 23.Удобочитаемость(легкость восприятия текста программ) 24.Расширяемость(способность ПС к использованию большого объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент) 25.Модифицируемость(ПС с точки зрения простоты внесения необходимых изменений на весх этапах ЖЦПС) 26.Модульность(ПС с точки зрения организации его программ из подпрограмм) 27.Независимость от устройств(способность ПС работать на разном аппаратном обеспечении) 6. Методы проектирования нисходящего проектирования. 1.Восходящие разработки 2.Нисходящие разработки (1) // вначале строится модульная структура программы в виде дерева, затем по очередно программируются модули программы начиная с модуля самого нижнего уровня в таком порядке, чтобы для каждого модуля были уже запрограммированы всем модули к которым он может обращаться, после того как все модули программы запрограммированы, производится их поочередное тестирование и отладка. Современная технология не рекомендует такой подход разработки программ, так как: Во первых для программирования какого либо модуля совсем не требуется наличие текстов используемых им модулей-(для этого достаточно, чтобы каждый модуль был специфицирован, а для тестирования его возможно использовать другие модули например драйвера) Во воторых каждая программа подчиняется некоторым внутренним для нее, но глобальными для ее модулей соображения (принципе структуре) ,что определяет ее целостность и формируется в процессе её разработки.При восходящей разработке информация для модуля нижних уровней ясна не вполном объеме, поэтому очень часто приходиться их перепрограммировать В третьих при восходящем тестировании для каждого модуля приходиться создавать главную программу, которая должна подготовить для тестируемого модуля необходимые состояния информационной среды (2) // заключается в построении модульной структуры программы в виде дерева,затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня(гланого) переходя к программированию, какого либо модуля только втом случаи,если модуль уже запрограммировали и к которому обращаются.После того, как всемоудли программв запрограммированы,производится их поочередное тестирование и отладка восходящем порядке, при этом первым тестируется галовной модуль который предусматривает всю тестируемую программу, при этом те модули к которым может обращаться галовной, заменяются их иммитаторами которые называются заглушками. Каждый иммитатор модуля представляется простым программным фрагментом, который в основном сигнализирует о самом факте обращения к иммитируемому модулю, производит обработку значений его входных параметров и выдает результат. После завершения тестирования и отладки галовного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены иммитаторами. Для этого иммитатор, выбранный для тестирования модуля, заменяется самим этим модулем и кроме того,добавляются иммитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль, при этом каждый такой модуль будет тестироватся при естественных состояниях информационной среды возникающих к моменту обращения к этому модулю. 7. Конструктивный подход Представляет собой моудфикацию нисходящей разработки,при которой модульная древовидная структура программы формируется в процессе программирования модулей. Разработка программы начинается с программирования галовного модуля, при этом программа получается объемной и необходимо выделять подзадачи, т.е внутренние функции. В галовном модуле программы для обращения к выделеной функции строится обращение галовному модулю указанного поддеревав соответствии с созданной его спецификацией. Архитектруный подход Представляет собой модификацию восходящей разработки при которой модульная структура программы формируется в процессе программирования модуля, при этом ставится цель- повышение уровня используемого языка программмрования, а не разработки конкретной программы, т.е для заданной предметной области выделяются типичные функции, каждая из которых может использоватся при решении разных задач, а затем программируются отдельные программные модули. Так как процесс выделения функций связан с накоплением и обработкой опыта решения задач, то сначала выделяются и реализуются отдельными модулями более простые функции, затем более сложные (важные) функции. Такое строение позволяет существенно сократить трудо затраты на ращработку конкретной программы путем подключения к ней заранее заготовленных модулей нижнего уровня. 8. Компьютерная поддержка разработки и сопровождения программных средств. Инструменты разработки программных средств Компилятор избавляет разработчика ПС от необходимости писать программы на языке компьютера, который для разработчика ПС был бы крайне неудобен, вместо этого он составляет программы на удобном ему языке программирования, которые соответствующий компилятор автоматически переводит на язык компьютера. Эмулятор позволяет выполнять (интерпретировать) программы на языке, отличном от языка компьютера, поддерживающего разработку ПС, например, на языке компьютера, для которого эта программа предназначена. ПС, предназначенное для поддержки разработки других ПС, будем называть программным инструментом разработки ПС, а устройство компьютера, специально предназначенное для поддержки разработки ПС, будем называть аппаратным инструментом разработки ПС. Инструменты разработки ПС могут использоваться в течение всего жизненного цикла ПС для работы с разными программными документами. Так текстовый редактор может использоваться для разработки практически любого программного документа. Разделение по функциям на группы: - редакторы; Редакторы поддерживают конструирование (формирование) тех или иных программных документов на различных этапах жизненного цикла. - анализаторы; Анализаторы производят либо статическую обработку документов, осуществляя различные виды их контроля, выявление определенных их свойств и накопление статистических данных, либо динамический анализ программ. - преобразователи; Преобразователи позволяют автоматически приводить документы к другой форме представления или переводить документ одного вида к документу другого вида, синтезировать какой - либо документ из отдельных частей и т.п. - инструменты, поддерживающие процесс выполнения программ. Инструменты, поддерживающие процесс выполнения программ, позволяют выполнять на компьютере описания процессов или отдельных их частей, представленных в виде, отличном от машинного кода, или машинный код с дополнительными возможностями его интерпретации. Инструментальные среды разработки и принципы их классификации. Инструментальной средой разработки называют совокупность логически связанной программных и аппаратных инструментов. Совокупность инструментальных сред можно разбивать на разные классы, которые различаются значением следующих признаков: - ориентированность на конкретный язык программирования, показывает: ориентирована ли среда на какой - либо конкретный язык программирования или может поддерживать программирование на разных языках программирования. - специализированность, показывает: ориентирована ли среда на какую - либо предметную область или нет. - комплексность; показывает: поддерживает ли она все процессы разработки и сопровождения ПС или нет. - ориентированность на конкретную технологию программирования; показывает: ориентирована ли инструментальная среда на фиксированную технологию программирования либо нет. - ориентированность на коллективную разработку; показывает: поддерживает ли среда управление работой коллектива или нет. - интегрированность; показывает: является ли она интегрированной (и в каком смысле) или нет.Инструментальная среда считается интегрированной, если взаимодействие пользователя с инструментами подчиняется единообразным правилам, а сами инструменты действуют по заранее заданной информационной схеме, связаны по управлению или имеют общие части. В соответствие с этим различают три вида интегрированности: - интегрированность по пользовательскому интерфейсу; означает, что все инструменты объединены единым пользовательским интерфейсом. - интегрированность по данным; означает, что инструменты действуют в соответствии с фиксированной информационной схемой (моделью) системы, определяющей зависимость друг от друга различных используемых в системе фрагментов данных. - интегрированность по действиям (функциям); означает, что, во - первых, в системе имеются общие части всех инструментов и, во - вторых, одни инструменты при выполнении своих функций могут обращаться к другим инструментам. Инструментальную среду, интегрированную хотя бы по данным или по действиям, будем называть инструментальной системой. При этом интегрированность по данным предполагает наличие в системе специализированной базы данных, называемой репозиторием. Под репозиторием будем понимать центральное компьютерное хранилище информации, связанной с проектом (разработкой) ПС в течение всего его жизненного цикла. Основные классы инструментальных средств. Три основных класса --||--: - инструментальные среды программирования; предназначена в основном для поддержки процессов программирования (кодирования), тестирования и отладки ПС. - рабочие места компьютерной технологии; ориентировано на поддержку ранних этапов разработки ПС (системного анализа и спецификаций) и автоматической генерации программ по спецификациям. - инструментальные системы технологии программирования. предназначена для поддержки всех процессов разработки и сопровождения в течение всего жизненного цикла ПС и ориентирована на коллективную разработку больших программных систем с продолжительным жизненным циклом. Инструментальные среды программирования. включает, прежде всего, текстовый редактор, позволяющий конструировать программы на заданном языке программирования, а также инструменты, позволяющие компилировать или интерпретировать программы на этом языке, тестировать и отлаживать полученные программы. Взаимодействуют эти инструменты между собой через обычные файлы с помощью стандартных возможностей файловой системы. Различают следующие: - среды общего назначения; содержат набор программных инструментов, поддерживающих разработку программ на разных языках программирования и обычно представляют собой некоторое расширение возможностей используемой операционной системы. Для программирования в такой среде на каком - либо языке программирования потребуются дополнительные инструменты, ориентированные на этот язык (например, компилятор). - языково - ориентированные среды. предназначена для поддержки разработки ПС на каком - либо одном языке программирования и знания об этом языке существенно использовались при построении такой среды. В такой среде могут быть доступны достаточно мощные возможности, учитывающие специфику данного языка. Такие среды разделяются на два подкласса: - интерпретирующие среды; обеспечивает интерпретацию программ на данном языке программирования, т.е. содержит, прежде всего, интерпретатор языка программирования, на который эта среда ориентирована. - синтаксически - управляемые среды. базируется на знании синтаксиса языка программирования, на который она ориентирована. Инструментальные системы технологии программирования. Это интегрированная совокупность программных и аппаратных инструментов, поддерживающая все процессы разработки и сопровождения больших ПС в течение всего его жизненного цикла в рамках определенной технологии. Она базируется на согласованности продукции технологических процессов. Обеспечивает контроль полноты создаваемой документации и согласованности её изменения. Поддерживает управление работой коллектива и для разных членов этого коллектива обеспечивает разные права доступа к различным фрагментам продукции технологических процессов и поддерживает работу менеджеров по управлению коллективом разработчиков. можно выделить три их основные компоненты: - репозиторий; - инструментарий; набор инструментов, определяющий возможности, предоставляемые системой коллективу разработчиков. - интерфейсы; Пользовательские и системные, пользовательский интерфейс обеспечивает доступ разработчикам к инструментарию. Он реализуется оболочкой системы. Системные интерфейсы обеспечивают взаимодействие между инструментами и их общими частями. Два класса ---||---: - Инструментальная система поддержки проекта - это открытая система, способная поддерживать разработку ПС на разных языках программирования после соответствующего ее расширения программными инструментами, ориентированными на выбранный язык. - Языково-зависимая инструментальная система - это система поддержки разработки ПС на каком - либо одном языке программирования, существенно использующая в организации своей работы специфику этого языка. 9. Объектный подход к разработки ПС Объект воплощает некоторую сущность и имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся с первым в каких-либо отношениях. Отношениесвязывает некоторые объекты: можно считать, что объединение этих объектов обладает некоторым свойством. Одноместное отношение называется простым свойством объекта. Многоместное отношение объектов будем называть ассоциативным свойством объекта, если этот объект участвует в этом отношении. Множество всех объектов, которые обладают каким-то общим набором свойств, называется классом объектов. С точки зрения разработчиков ПС следует различать следующие категории объектов объекты модельного (вещественного или умственного) мира, информационные модели объектов реального мира (будем называть их пользовательскими объектами); объекты процесса выполнения программ; объекты процесса разработки ПС (технологические объекты программирования). Объектный мир состоит из 3ёх частей: (тели это три модели я не знаю) - объектной модели; показывает статическую объектную структуру модельного мира, который должно представлять разрабатываемое ПС (программная система). Она включает определения используемых классов объектов и отношений между этими классами, а также определение используемых объектов этих классов и отношения между этими объектами. Обычно класс объектов в объектной модели представляется в виде тройки (Имя класса, Список атрибутов, Список операций). Отношение между двумя (и более) объектами называют связями, а их обобщение (отношение между классами) обычно называют ассоциациями. - динамической модели; Показывает допустимые последовательности изменений состояний объектов из объектной модели модельного мира, который должно представлять разрабатываемое ПС (программная система). Она описывает последовательности операций в ответ на внешние сигналы (взаимодействия) без рассмотрения того, что эти операции делают. Динамическая модель необходима, если в соответствующей объектной модели имеются активные объекты. Основные понятия динамической модели: Под событием здесь понимается элементарное воздействие одного объекта на другой, происходящее в определенный момент времени. Под состоянием объекта здесь понимается совокупность значений атрибутов объекта и представления текущих связей этого объекта с другими объектами. Условие – это предикат, зависящий от значений некоторых атрибутов объекта. - функциональной модели; показывает, как вычисляются выходные значения из входных без указания порядка, в котором эти значения вычисляются. Она определяет все операции, условия и ограничения, используемые в объектной и динамической моделях. Для определения крупных операций в функциональной модели используются потоковые диаграммы. Основными понятиями потоковых диаграмм являются процессы, объекты и потоки данных. Потоковая диаграмма – это граф, вершинами которого являются объекты или процессы, а дугами – потоки данных. Процессы преобразуют данные, поступающие от одних объектов и направляемые для хранения в другие объекты. Объекты могут быть пассивными (хранилищами данных) и активными (агентами). Пассивные объекты используются только для хранения данных, а активные объекты используются как для хранения, так и для преобразования данных. Потоки данных определяют допустимые направления перемещения данных и типы перемещаемых данных. 10. Структурное программирование Методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. В соответствии с данной методологией: 1) Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций: последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы; ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия; цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла). В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается. 2) Повторяющиеся фрагменты программ. В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы. 3) Разработка программы ведётся пошагово, методом «сверху вниз». Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки», которая не была бы удалена. 11.Объектно-ориентированное программирование (ООП) Представляет собой способ программирования который напоминает процесс человеческого мышления. ООП более структурировано, чем др. способы программирования и позволяет создавать модульные программы с представлением данных на определенном уровне абстракции. Цель ООП – это повышение эффективности разработки программ. Базовым в ООП является понятие объекта, который имеет определенные свойства; состояния объекта задается значениями его признаков; объекты могут взаимодействовать др с другом. Концепция ООП заключается в том, что каждый объект является экземпляром некоторого класса объектов. Все объекты с одинаковыми наборами атрибутов принадлежат одному классу. Каждый класс имеет свои особенности поведения и характеристики определяющих этот класс. Один класс отличается от других именем и интерфейсом который представляет собой набор сообщений, которые можно посылать объекту. ООП является наилучшим инструментом для построения иерархических деревьев или структур данных. Характеристики ООП: 1.Всё является объектом. 2.Вычисления осуществляются путем взаимодействия между объектами при котором один объект требует чтобы др объект выполнил некое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщения – это запрос на выполнение действия дополненный набором атрибутов, которые могут понадобиться при выполнении действии. 3.Каждый объект имеет независимую память которая состоит из др объектов. 4.Каждый объект является представителем класса который выражает общие свойства объектов. 5.В классе задается функциональность, т.е. поведение объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия. 6.Классы организованны в единую древовидную структуру с общим корнем называемую иерархией наследования. Память и поведение связанное с экземплярами определенного класса автоматически доступны любому классу расположенному ниже в иерархическом дереве. Принципы ООП: 1.Абстракция данных. Это выделение существующих характеристик объекта, которые отличают его от всех др видов объектов, и таким образом четко определяют его концептуальные границы относительно его дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. 2.Инкапсуляция. Объект – скрывает в себе детали которые не существенны для использования. В традиционном подходе к программированию с использованием глобальных переменных, программист не застрахован от ошибок связанных с использованием процедур не предназначенных для обработки этих данных но связанных с этими переменными. Инкапсуляция – это принцип по которому любой класс (тип описывающий устройства объектов) должен рассматриваться как черный ящик – должен видеть и использовать только интерфейс класса и не вникать в его внутреннюю реализацию. Этот принцип позволяет минимизировать число связей между классами, т.е. упрощаем программу. 3.Наследование. Позволяет определить новые объекты используя свойства прежних, дополняя или изменяя их. Наследование называется возможность порождать один класс от другого сохранением всех свойств и методов, при этом добавляя при необходимости новые свойства и методы. При наследование программа принимает структуру иерархичности. 4.Полиморфизм. Заключается в том, что одно и тоже имя может соответствовать различным действиям в зависимости от типа объекта. Называют явление при котором классы потомки могут изменять реализацию метода класса предка. 12.Архитектура ПП. Это строение как оно видно или должно быть видно из вне его, т.е. представление ПП как системы состоящей из совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПП на котором реализуется принцип выделения относительно независимых компонентов. К основным задачам относятся: 1. Выделение программных подсистем и отображения на них внешних функций. 2. Определение способов взаимодействия между выделенными программными подсистемами. Основные классы архитектур ПП. 1.Цельная программа Цельная программа представляет вырожденный случай архитектуры ПП. В состав ПП входит только одна программа. Данную архитектуру выбирают обычно в том случае, когда ПП выполняет одну из функций (главных) и её реализация не представляется слишком сложной. Такая архитектура не требует, какого либо описания, и не требуется определить способ взаимодействия между функциями. 2.Комплекс автономно выполняемых программ А) Состоит из набора программ, причем любая из этих программ может быть активизирована пользователем. Б) Все программы применяются к одной и той же инфо среде. В) При выполнении активизированной программы другие программы заблокированы. 3.Сложная программная система. 4.Коллектив параллельно выполняемых программ. 13. Оптимизация программы. Это улучшение, какой либо характеристики программы называемой критерием оптимизации. ОП в основном выполняется по двум критериям: - быстродействие; - объем используемых данных; Процесс оптимизации следует начать с профилировки программы. – измерение производительности, как всей программы так и её отдельных фрагментов с целью нахождения «горячих точек» - тех участков программы на выполнение которых расходуется наибольшее количество времени. В зависимости от степени детализации в качестве точки рассматривается либо отдельная машинная команда, либо целая конструкция (функция, цикл). Сложная программа состоит из большого числа функций, поэтому нет смысла их оптимизирования – трудоемкость такого подхода будет выше выгод полученных от оптимизации программы в целом. Для начала необходимо локализовать участки кода с максимальной вычислительной трудоемкости. Участки программы, которые в наибольшей в степени влияет на её производительность, в силу её частого выполнения, или своей ресурсоемкостью, называется критическим кодом. В его поиске используют профайлеры (профилировщики – это специальные программы которые измеряют временные затраты на выполнение участков кода программы). Большинство современных профилировщиков поддерживают следующий набор функций: Определение общего времени исполнения каждой точки программы. Определение причины или источника конфликтов. Определение количества вызовов в той или иной точки программы. Основные правила оптимизации: 1) Прежде чем приступить к оптимизации необходимо иметь надежно работающий неоптимизированный вариант; 2) Основной прирост оптимизации дает алгоритмическая оптимизация; 3) Обнаружив профайлировщиком узкие места необходимо произвести оптимизацию с помощью ЯВУ. Требования к оптимизации алгоритма: 1) Оптимизация должна быть по возможности максимально машинно не зависимой и переносимой на другие ОС без существенных потерь эффективности; 2) Алгоритм должен занимать размер в пределах допустимого; 3) При внесении изменений в алгоритм не должна страдать вся программа. 14. Методы тестирования: 1) Метод черного ящика Идея тестирования состоит в том, чтобы составить список, который перечисляет возможные ошибки и ситуации, в которых эти ошибки могли проявиться. Далее на основе списка составляются тесты. Все внутренние особенности реализации системы скрыты от тестировщика, т. е. система представляет собой черный ящик. ЧЯ - это набор модулей с известным внешним интерфейсом, но не доступными исходными тестами. Задача тестирования состоит, в последовательной проверки соответствия поведения системы требованиям. При тестировании выявляются два типа проблем с системой: 1)) Не соответствие поведения системы; 2)) Неадекватное поведение с системой в ситуации не предусмотренных требованиям. |