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

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

1 2

4.Дайте определение таблицы решений. Приведите пример.*

Таблица решений – это такая внешняя спецификация ПО, в которой отражаются комбинации условий, выполняемых для входных данных, и соответствующие этим комбинациям действия по преобразованию информации.

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

б) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки; в) если очередной символ не находится в заданном диапазоне, (положим, от ‘а’ до ‘я’), то подать звуковой сигнал и вернуть код ошибки;

г) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика. Таблица решений для данного примера приведена ниже ( таблица 1.1). Здесь ‘Д’ означает ‘да’, ‘Н’ - ‘нет’, 1,2 - помеченные действия выполняются в указанном порядке.

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

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

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

7.Дайте определение спецификациям ПО, назовите известные Вам внешние

спецификации и их особенности. Приведите пример спецификации.*

Под спецификацией понимается формально описание требований, свойств и функций объекта. Наиболее распространено специфицирование с помощью таблиц решений. Проектирование спецификаций процессов с помощью таблиц решений (ТР) заключается в задании матрицы, отображающей множество входных условий и множество решений.

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа ‘да-нет’. Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Левая часть ТР содержит собственно описание условий и действий, а в правой части перечисляются все возможные комбинации условий и, соответственно, указывается, какие конкретно действия и в какой последовательности выполняются, когда определенная комбинация условий имеет место.
8. Назовите группы символы, которые используются в схемах проектов ПО согласно ГОСТ, и приведите примеры таких символов. *

В схемах проектов ПО согласно ГОСТ используются 4 вида символов: символы данных, символы процесса, символы линий и специальные символы.

Символы данных: основные – данные, запоминаемые данные; специфические – оперативное запоминающее устройство, запоминающее устройство с последовательной выборкой (ЗУПВ), запоминающее устройство с прямым доступом (ЗУПД), документ, карта, бумажная лента, дисплей. Символы процесса: основные – процесс; специфические – предопределённый процесс, ручная операция, подготовка, решение, параллельные действия, граница цикла. Символы линий: основные - линия; специфические – передача управления, канал связи, пунктирная линия. Специальные символы: соединитель, терминатор, комментарий, пропуск.
9.Дайте определение схемы, перечислите схемы, которые используются при документировании ПО, и их назначение. Приведите пример какой-либо схемы и назовите группы символов, которые в таких схемах применяются.*

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

-схемы данных;

-схемы программ;

-схемы работы системы;

-схемы взаимодействия программ;

-схемы ресурсов системы.

Схемы данных отображают путь данных при решении задач и определяют этапы обработки и применяемые носители данных.

Схемы программ отображают последовательность операций в программе.

Схемы работы системы отображают управление операциями и поток данных в системе.

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

Схемы ресурсов системы отображают конфигурацию блоков данных и обрабатывающих блоков, требуемую для решения задачи или набора задач.
10. Приведите пример и дайте пояснения редуцирования таблицы решений для какой-либо внешней спецификации.*
Редуцирование таблицы решений

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

Вх. условия	1	2	3	4
С1	да	да	нет	нет
С2	да	нет	да	нет
Решения
D1	1	1	1
D2	2		2	1
D3		2		2

11. Назовите нотации и приведите пример нотации для изображения структурных алгоритмов.*

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

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

Например модуль вычисления суммы , может использоваться в разных контекстах, и в зависимости от контекста изменяется и смысл связей между предложениями модуля.

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

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

Пример: библиотека стандартных программ, реализующих численные методы.

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

3. Прочность по классу – модуль выполняет несколько функций, отнесенных разработчиком к одному классу. Например: autoexec.bat.

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

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

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

5. Коммуникационно- прочный модуль. Это процедурно прочный модуль, в котором все функции модуля связаны по данным.

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

6. Информационная прочность – модуль выполняет несколько функций над одной и той же строкой данных, но каждая функция представляется отдельным входом в модуль.

7. Функциональная прочность – это когда модуль выполняет одну функцию – это то, к чему следует стремиться при проектировании модульной структуры ПО. Информационно - прочные модули следует рассматривать как физическое соединение нескольких функционально – прочных модулей.

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

13. Дайте определение сцепления модулей и приведите примеры модулей с разными видами сцепления.*

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

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

1. Сцепление по содержимому – модуль ссылается на данные (содержимое) другого модуля. Большинство языков программирования высокого уровня делает такое сцепление практически невозможным.

2. Сцепление по общей области – модули ссылаются на одну и ту же глобальную структуру данных.

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

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

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

4. Сцепление по формату – модули ссылаются на одну и ту же структуру данных. Если модуль А вызывает модуль В и передает ему запись анкетных данных служащего и при этом как А так и В чувствительны к изменению структуры или формата записи, то А и В сцеплены по формату.Такого сцепления, по возможности, следует избегать, поскольку оно создает ненужные связи между модулями.

5. Сцепление по данным – передаваемые параметры – простые (неструктурированные) данные.

Сцепление модулей может удовлетворять определению нескольких типов сцепления. В этом случае принято относить тип сцепления к самому жесткому типу, т.е. к меньшему по номеру из рассмотренных типов сцеплений.
14.Дайте определение технологии программирования. Какие технологии Вы знаете и к каким периодам относится появление этих технологий? *

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

CASE-системами или CASE-технологиями называют реализованные в виде программных продуктов технологические системы, ориентированные на создание сложных программных систем и поддержку их полного жизненного цикла или его основных этапов.
15. Дайте определение объектно-ориентированного программирования (ООП). Назовите и охарактеризуйте основные свойства ООП.*

Обьектно–ориентированное программирование - это подход, в котором данные и поведение (методы обработки данных) жестко связаны. Данные и поведение представлены в виде классов, экземпляры которых - объекты. ООП позволяет пользователю вводить собственные типы данных, расширяя тем самым набор встроенных в язык типов данных. Для обозначения этих расширений используется термин абстрактные типы данных (АТД). Основными свойствами ООП являются инкапсуляция, наследование и полиморфизм. Под инкапсуляцией понимается сокрытие данных и операций АТД от внешних программ, использующих их. Наследование - это средство получения новых типов данных (классов) из уже существующих типов, называемых базовыми классами. При этом повторно используется существующий код. Порождённый класс образуется из базового путем добавления или изменения кода. Полиморфизм - средство для придания различных значений одному и тому же сообщению в зависимости от типа обрабатываемых данных. Например, если аргументы оператора целого типа, то используется целочисленное деление. Если же один или оба аргумента - значения с плавающей точкой, то используется деление с плавающей точкой.
16. Блочно-иерархический подход к созданию программных систем.*

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

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

17. Проблемы разработки сложных программных систем.*

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

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

Дополнительными факторами, увеличивающими сложность разработки программных систем, являются [2]:

• сложность формального определения требований к программным системам;

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

• коллективная разработка;

• необходимость увеличения степени повторяемости кодов.
18. Дайте определение модели жизненного цикла (ЖЦ) программного продукта (ПП). Каскадная модель ЖЦ ПП. Область применения, достоинства и недостатки.*

ЖЦ представляет собой непрерывный процесс, продолжающийся достаточно длительное время от момента принятия решения о создании информационной системы и заканчивая моментом изъятия ее из эксплуатации. В этом временном промежутке выделяют фазы, стадии, этапы.

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

Традиционная модель ЖЦ ПО строится по каскадному принципу, суть которого в том, что переход на следующий этап происходит после окончания предыдущего.

Каскадная модель получили еще и другое название “водопад”. Эта модель имеет ряд положительных качеств, благодаря которым она хорошо себя зарекомендовала и получила широкое распространение:

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

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

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

Перечень недостатков каскадной модели более обширен, чем перечень ее достоинств:

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

19. Этапы жизненного цикла (ЖЦ) программных продуктов (ПП). Схема ЖЦ ПП.*

Анализ

Проектирование

Программирование

Тестирование и отладка

Изготовление

Эксплуатация и сопровождение

Эксплуатация и сопровождение
Тестирование и отладка
Программирование
Проектирование
Анализ
20. Функциональное и структурное тестирование программ: цели, отличия стратегий, рекомендации по применению.*

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

Функциональное тестирование(черного ящика) применяют на более поздних стадиях тестирования для выявления и устранения ошибок интерфейса, а также некорректных и отсутствующих функций обработки данных.
21. Этапы тестирования программ. Стадии тестирования в процессе разработки программного обеспечения. Методы, используемые на каждой стадии.*

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

Стадии:

1) автономное тестирование компонентов программного обеспечения (методы ручного контроля, покрытия операторов, покрытия решений, покрытия условий, комбинаторного покрытия).

2) комплексное тестирование разрабатываемых программ (восходящее и нисходящее тестирование).

3) системное или оценочное тестирование на соответствие основным критериям качества.
22. Ручной контроль как метод тестирования.* *

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

23. Методы структурного тестирования. Общий недостаток методов.* //белый ящик

1 - метод покрытия решений (переходов),

2 - метод покрытия операторов,

3 - метод покрытия условий,

4 - метод комбинаторного покрытия условий.

Применяются при тестировании логики программного модуля. Для применения этих методов на практике структура программы должна быть известной.
24. Методы функционального тестирования. Области применения.* //черный ящик

эквивалентного разбиения

анализа граничных значений

таблиц решений

функциональных диаграмм
25. Основные положения метода эквивалентного разбиения.*

а) каждый тест должен включать столько различных входных условий, сколько это возможно, с тем чтобы минимизировать общее число тестов;

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

26. Основные положения метода граничных значений.*

Определение: граничные условия это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности.

Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях:

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

- при разработке тестов рассматривают не только входные условия (пространство входов), но и пространство результатов, то есть выходные классы эквивалентности.
27. Пошаговое тестирование модульных программ. Достоинства и недостатки подходов.*

Методика восходящего тестирования включает следующие щаги: Сначала тестируются ‘листья’ дерева структуры программы, т.е. модули Е,C,F. Поскольку это вызываемые программы, то для их тестирования программируются драйверы. В его функции входит формирование тестовых данных для отлаживаемого модуля и передача ему управления (вызов модуля). Затем аналогично тестируются модули вышележащего уровня совместно с уже оттестированными модулями нижележащего уровня. Применительно к рассматриваемому нами примеру проектируются драйверы для тестирования пар B-E и D-F. Пошаговый процесс продолжается до тех пор, пока не будет включен в процесс тестирования последний модуль. Для нашего примера это будет модуль А. Для его тестирования совместно с вызываемыми программами нижележащего уровня драйвер разрабатывать не требуется.

Альтернативное нисходящее тестирование состоит из следующих действий: Тестирование начинается с вызывающего модуля программы. Для модулей нижележащего уровня (вызываемых) программируются так называемые ‘заглушки’. После проверки ‘корня’ дерева структуры комплексной программы переходят к тестированию нижележащих модулей. Причем, формализованной процедуры подключения к вызывающему модулю нижележащих вызываемых модулей не существует. Единственное ограничение, которым руководствуются при выборе очередного претендента на тестирование, заключается в том, что этот модуль должен вызываться уже оттестированным модулем вышележащего уровня. Если очередной тестируемый модуль вызывает модули еще нижележащего уровня, то аналогично пункту а) для нижележащих модулей программируются ‘заглушки’ Процесс тестирования продолжается до тех пор, пока не будет оттестирован последний модуль из ‘листьев’ дерева структуры программы.

28. Классификация и проявление ошибок программирования.*

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

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

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

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

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

Пропуск некоторых операторов.
Отсутствие необходимых данных.
Непредусмотренные данные.
Неверный формат данных.

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

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

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

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

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

Противоречивые команды.
Отсутствие условий окончания цикла.
Дублирование или отсутствие меток.
Отсутствие описания массива.
Запрещенный переход.

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

Присваивание.
Ввод.
Чтение из файла.

Разные прогоны программы с одними и теми же данными могут привести к различным результатам
29. Методы отладки программ.*

1) метод индукции;

2) метод дедукции.

Название методов напоминают о криминалистике и не напрасно, ибо есть аналогия между этими методами и расследованием преступления.

Метод индукции включает:

1) определение данных тестирования, имеющих отношение к ошибке;

2) анализ от частного к общему позволит выявить закономерности в данных пункта 1);

3) в результате анализа (п.2) выдвигается гипотеза о причине ошибки;

4) для подтверждения гипотезы 3 разрабатывается один или больше тестов, которые должны либо подтвердить, либо опровергнуть гипотезу; если дополнительные тесты подтверждают гипотезу, можно приступать к исправлению ошибки, а вот если не подтверждают, то требуется в лучшем случае возврат к п.3, а в худшем - к п.2.

Альтернативный метод дедукции заключается в:

1) перечисление возможных причин или гипотез:

2) использование данных тестирования для исключения некоторых возможных причин;

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

4) доказательство выбранной гипотезы совпадает с п.4 и п.5 метода индукции.
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. Структурное программирование. Определение подхода, цель и принципы.*

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

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

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

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

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

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

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

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

в) цикл

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

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

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

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

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