Главная страница
Навигация по странице:

  • 31. Общая методика отладки программ.*

  • 32. Критерии качества программ.*

  • 33. Стиль оформления программ.*

  • 34. Эффективность программ: способы экономии памяти.*

  • 35. Эффективность программ: способы экономии времени выполнения.* *

  • 36. Программирование “с защитой от ошибок”.*

  • 37. Стихийное программирование. Этапы совершенствования архитектуры программ.*

  • 38. Структурное программирование. Определение подхода, цель и принципы.*

  • 39. Нисходящая стратегия разработки программ.*

  • 40. Принципы модульного программирования.* *

  • 41. Основные понятия объектно-ориентированного программирования.* Основными понятиями ООП являются объект

  • Объектом

  • 42. Достоинства и недостатки объектно-ориентированного программирования.*

  • 43. CASE-технологии как результат эволюционного развития инструментальных средств.*

  • 44. Сравнение этапов жизненного цикла в CASE-технологиях и при традиционной разработке ПО.*

  • 45. Спиральная модель жизненного цикла программных продуктов.*

  • 46. Дайте определение модели жизненного цикла ПП. Приведите каскадную и спиральную модели ЖЦ и дайте краткие пояснения. *

  • Вопросы с ответами 2018.doc. 1. Назовите цель разбиения исходных данных программ на классы эквивалентности. Приведите пример выделения классов эквивалентности для какойлибо задачи (в виде дерева разбиения)


    Скачать 297.5 Kb.
    Название1. Назовите цель разбиения исходных данных программ на классы эквивалентности. Приведите пример выделения классов эквивалентности для какойлибо задачи (в виде дерева разбиения)
    Дата19.01.2019
    Размер297.5 Kb.
    Формат файлаdoc
    Имя файлаВопросы с ответами 2018.doc.doc
    ТипДокументы
    #64352
    страница3 из 3
    1   2   3

    30. Методы получения дополнительной информации об ошибках.*

    Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят:

    1) отладку с использованием дампа памяти;

    2) отладку с использованием операторов печати по всей программе;

    3) отладку с использованием автоматических средств.

    Дампы памяти практически невозможно использовать при программировании на языке высокого уровня, поэтому на этом способе отладки останавливаться не будем

    Расстановка печатей в программе бессистемно вряд ли может ускорить отладку. Для системной расстановки нужны четкие представления о структуре алгоритма (схема работы программы или блок-схема). Серьезным недостатком этого метода отладки является тот факт, что печати, вставляемые в программу, изменяют ее, вследствие чего могут послужить дополнительным источником ошибок.
    31. Общая методика отладки программ.*

    1й этап – изучение проявления ошибки. Результатом выполнения этапа должна быть локализация ошибки. При этом можно использовать методы индукции и дедукции и средства получения дополнительной информации об ошибке.

    2й этап – выполняется, если произошло “зависание” или не удалось локализовать ошибку, используя методы 1го этапа

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

    4й этап – исправление ошибки. Здесь нужно помнить 1 вещь – небрежное исправление может породить новые ошибки.

    5й этап – повторное тестирование
    32. Критерии качества программ.*

    1) функциональность

    2) надежность

    3) легкость применения

    4) эффективность

    5) сопровождаемость

    6) мобильность

    Функциональность - это способность выполнять набор функций, определенных его внешними спецификациями.

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

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

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

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

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

    1) правила именования объектов программы(переменных, функций, типов данных и тп)

    2) правила оформления модулей

    3) стиль оформления текстов программ
    34. Эффективность программ: способы экономии памяти.*

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

    Прежде всего, при наличии ограничений на использование памяти следует выбирать алгоритмы обработки, не требующие дублирования исходных данных структурных типов в процессе обработки. Примером могут служить алгоритмы сортировки массивов, выполняющие операцию в заданном массиве, например, хорошо известная сортировка методом "пузырька".
    35. Эффективность программ: способы экономии времени выполнения.* *

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

    Первый способ связан с учетом времени выполнения операций в ЭВМ:

    • сложение и вычитание выполняются быстрее, чем умножение и деление (в связи с чем Х+Х выполнясгся быстрее, чем 2*Х)

    • целочисленная арифметика быстрее арифметики вещественных чисел (поэтому (i+i+j)* 0,5 быстрее» чем i+0,5*j, так как в первомварианте одна операция с вещественными числами, а во втором – две)

    • в целочисленной арифметике операции умножения иди деления на числа, кратные 2, можно заменить соответствующим количеством сдвигов.

    • обращение к функции требует больших временных затрат, чем умножение и деление.

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

    При их написании необходимо по возможности:

    1) выносить вычисление константных, т.е. не зависящих от параметров цикла выражений из циклов.

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

    3) минимизировать преобразования типов в выражениях

    4) оптимизировать запись условных выражений – исключать лишние проверки.

    5) исключать многократные обращения к элементам массивов по индексам

    6) избегать использования различных типов в выражении и т.п.
    36. Программирование “с защитой от ошибок”.*

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

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

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

    Детальный анализ ошибок и их возможных ранних проявлений показывает, что целесообразно проверять:

    • правильность выполнения операций ввода-вывода;

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

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

    • ошибки передачи - аппаратные средства, например вследствие неисправности, искажают данные;

    • ошибки преобразования - программа неверно преобразует исходные данные из входного формата во внутренний формат;

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

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

    Обнаружить и устранить ошибки перезаписи можно, только если пользователь вводит избыточные данные» например, контрольные суммы. Если ввод избыточных данных по каким-либо причинам нежелателен, то следует по возможности проверять вводимые данные, хотя бы контролировать интервалы возможных значений, которые обычно определены в техническом задании, и выводить введенные данные для проверки пользователю. Неверные данные обычно может обнаружить только пользователь.
    37. Стихийное программирование. Этапы совершенствования архитектуры программ.*

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

    Главный недостаток разработанного таким образом ПО – большие трудности его сопровождения. Программы, написанные без регламентации применения операторов языка программирования, имеют структуру “итальянского спагетти” из-за частого применения в таких программах оператора перехода goto. Как правило, в таких программах может разобраться только автор, они плохо пригодны для тиражирования и превращения в товар.

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

    Знаменательной датой в истории программирования стал 1968 год. Тогда создавшееся в программировании положение обсуждалось на международной конференции, получившей название “Кризис программного обеспечения”. В этом году Чарльз Хоар и Николаус Вирт впервые указали на необходимость придания языку программирования свойств, которые превратили бы его в “инструмент надежного создания сложных программ”. Однако настоять на этом им не удалось.

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

    38. Структурное программирование. Определение подхода, цель и принципы.*

    Цель структурного программирования – разработка программы, которой присуща определенная структура, основанная на применении принципов структурного программирования.

    Перечислим эти принципы:

    1. Каждый программный модуль (блок, функция, процедура) должен иметь только один вход и один выход.


    Это позволяет максимально упростить стыковку модулей в программе.

    1. В программах рекомендуется применять 4 типа конструкций:

    а) последовательность (модулей, операторов)



    б) разветвление (условный оператор)



    Перечеркивание означает, что Q может отсутствовать.

    в) цикл

    1. с предусловием



    1. с постусловием



    г) выбор из нескольких альтернатив (или переключатель)



    1. разработку программ рекомендуется вести сверху – вниз или по нисходящей стратегии.


    39. Нисходящая стратегия разработки программ.*

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

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

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

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

    Модуль – это программа, обладающая тремя основными атрибутами:

    он выполняет одну или несколько функций;

    модуль реализует некоторую логику (алгоритм).

    используется в одном или нескольких контекстах.

    При этом функция – это то, что делает модуль, а не то, как он это делает. А вот логика характеризует, как модуль выполняет свои функции. Контекст описывает конкретное применение.
    41. Основные понятия объектно-ориентированного программирования.*

    Основными понятиями ООП являются объект (экземпляр класса), класс, метод и сообщение (запрос)

    Класс - это структура данных, которая может содержать в своем составе переменные, функции и процедуры.

    Объектом или экземпляром класса называется переменная объектного типа ( или переменная типа класс).

    Методы – операции обработки.

    Сообщением является совокупность данных определенного типа, передаваемых объектом-отправителем объекту-получателю, имя которого указывается в сообщении.
    42. Достоинства и недостатки объектно-ориентированного программирования.*

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

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

    • Данные и операции вместе образуют определенную сущность, и они не «размываются» по всей программе, как это нередко бывает в случае процедурного программирования.

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

    • Инкапсуляция информации защищает наиболее критичные данные от несанкционированного доступа.


    43. CASE-технологии как результат эволюционного развития инструментальных средств.*

    CASE-системами или CASE-технологиями называют реализованные в виде программных продуктов технологические системы, ориентированные на создание сложных программных систем и поддержку их полного жизненного цикла или его основных этапов.

    CASE-технологии являются естественным продолжением эволюции всей отрасли разработки ПО. Традиционно выделяют 6 периодов, качественно отличающихся применяемой техникой и методами разработки ПО.

    В качестве инструментальных средств в эти периоды использовались:

    • ассемблеры, дампы памяти, анализаторы;

    • компиляторы, интерпретаторы, трассировщики;

    • символические отладчики, пакеты программ;

    • системы анализа и управления исходными текстами;

    • CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (1-ая генерация CASE-1);

    CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного ЖЦ разработки ПО (2-ая генерация CASE-II).

    CASE-технологии начали развиваться с целью преодоления ограничений методологии структурного программирования.
    44. Сравнение этапов жизненного цикла в CASE-технологиях и при традиционной разработке ПО.*

    При использовании CASE-технологий изменяются фазы жизненного цикла ПП как показано ниже:

    При традиционной технологии: При CASE-технологии:

    Анализ Прототипирование

    Проектирование Проектирование спецификаций

    Контроль проекта

    Кодирование Кодогенерация

    Тестирование Системное тестирование

    Сопровождение Сопровождение
    45. Спиральная модель жизненного цикла программных продуктов.*

    CASE-технология базируется на спиральной модели ЖЦ ПП, суть которой в следующем. Делается упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Все эти этапы выполняются на каждом витке спирали ЖЦ. Каждый виток спирали соответствует некоторому уровню детализации проекта Каждый следующий виток характеризуется более высокой степенью детализации создаваемого ПО. Каждый виток заканчивается тем, что уточняются цели и характеристики проекта и планируются работы следующего витка спирали. Тем самым реализуется нисходящий принцип проектирования.
    46. Дайте определение модели жизненного цикла ПП. Приведите каскадную и спиральную модели ЖЦ и дайте краткие пояснения. *
    Модель ЖЦ ПП определяет перечень этапов преобразования программа -> программное средство -> программный продукт, порядок выполнения этапов, а также критерии перехода от этапа к этапу. Традиционная модель ЖЦ ПО строится по каскадному принципу, суть которого в том, что переход на следующий этап происходит после окончания предыдущего. Единственным недостатком такой простой модели ЖЦ является то, что на практике очень часто принятые на предыдущем этапе (или на предыдущих этапах) решения приходится пересматривать из-за неверной интерпретации требований заказчика. Другая модель ЖЦ ПП строится по поэтапному принципу с промежуточным контролем. Критерием перехода на следующий этап является готовность документов, о которых было упомянуто выше. Такая модель является более жизнеспособной по сравнению с каскадной моделью, но наличие циклов обратных связей растягивает все этапы ЖЦ ПП на весь период разработки, что, в свою очередь, затрудняет планирование работ по созданию и внедрению программных продуктов. CASE-технология базируется на спиральной модели ЖЦ ПП, суть которой в следующем. Делается упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Все эти этапы выполняются на каждом витке спирали ЖЦ. Каждый виток спирали соответствует некоторому уровню детализации проекта. Каждый следующий виток характеризуется более высокой степенью детализации создаваемого ПО. Каждый виток заканчивается тем, что уточняются цели и характеристики проекта и планируются работы следующего витка спирали. Тем самым реализуется нисходящий принцип проектирования.
    Традиционная модель ЖЦ ПО строится по каскадному принципу (переход на следующий этап происходит после окончания работ по предыдущему этапу) или по поэтапному принципу с промежуточным контролем (с циклами обратной связи между этапами, что предполагает корректировки в процессе проектирования, но растягивает все этапы на весь период разработки). Суть спиральной модели ЖЦ ПО в следующем. Делается упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Все эти этапы выполняются на каждом витке спирали ЖЦ. Каждый виток спирали соответствует некоторому уровню детализации проекта. Каждый следующий виток характеризуется более высокой степенью детализации создаваемого ПО. Каждый виток заканчивается тем, что уточняются цели и характеристики проекта и планируются работы следующего витка спирали.
    1   2   3


    написать администратору сайта