ИГА. Понятие базы данных

• Название: Понятие базы данных
• Дата: 05.04.2022
• Размер: 0.77 Mb.
• Имя файла: ИГА.docx
• Тип: Документы; #445246
• страница: 35 из 37

Оптимизация программ.

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

^ Выбор алгоритма

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

Инициализация переменных и ввод-вывод данных. 

Организация циклов. 

Пример. Изменение вложенности циклов позволяет уменьшить число инициализаций цикла с 1101 до 23, а число проверок на окончание цикла с 3100 до 2022.

! число инициализаций цикла

c1 do i=1,100 ! 1

c2 do j=1,10 ! 100 

c3 do k=1,2 ! 1000

<тело цикла> ! 1101

! число проверок цикла

enddo c3 ! 2000

enddo c2 ! 1000

enddo c1 ! 100

! 3100 

После изменения вложенности циклов имеем следующую программу:

! число инициализаций цикла

c3 do i=1,2 ! 1

c2 do j=1,10 ! 2 

c1 do k=1,100 ! 20

<тело цикла> ! 23

! число проверок цикла

enddo c1 ! 2000

enddo c2 ! 20

enddo c3 ! 2

! 2022

Пример эффективного использования третьего параметра цикла.

do i=1,10  j=3*i+4  x(j)=y(j)+c enddo

do i=7,34,3  x(i)=y(i)+c enddo

Пример развертки цикла.

do i=1,n  a(i)=b(i)*c(i)  enddo

do i=2,n,2  a(i-1)=b(i-1)*c(i-1) a(i)=b(i)*c(i) enddo

Пример разъединения цикла и исключения избыточной проверки.

do i=1,100  if(flag) then  a(j)=b(j)-c(i) else a(i)=b(i)+c(i) endif  enddo

if(flag) then c1 do i=1,100  a(i)=b(i)-c(i) enddo c1 else c2 do i=1,100 a(i)=b(i)+c(i) enddo c2 endif

Организация переходов. 

Запись выражений (понижение мощности операций, исключение смешанной арифметики). 

Пример понижения мощности иллюстрирует применение схемы Горнера для вычисления полиномов. Пусть n=5.

y = a(0)*x**5 + a(1)*x**4 + a(2)*x**3 + a(3)*x**2 + a(4)*x**1 + a(5)

без возведения в степень

y = ((((a(0)*x + a(1))*x + a(2))*x + a(3))*x + a(4))*x + a(5)

Использование символьных типов данных.

Использование общих областей. 

Отладка и тестирование программ.

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

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

Отладка не является разновидностью тестирования, хотя слова «отладка» и «тестирование» часто используют как сино­нимы. Под ними подразумеваются разные виды деятельности:

- тестирование — деятельность, направленная на обна­ружение ошибок;

- отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки;

- результаты тестирования являются исходными данными для отладки.

Эти два вида деятельности очень тесно связаны и поэтому они обычно рассматриваются совместно.

В результате отладки программное обеспечение должно соот­ветствовать определенной фиксированной совокупности правил и показателей качества, принимаемой для него за эталонную. Иными словами: отладка — это этап разработки, на котором устраняются недостатки только что созданного программного обеспечения.

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

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

Отладку можно разделить на синтаксическую и семанти­ческую.

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

В отличие от синтаксической ошибки, семантическая ошибка не формализуемаи поэтому она составляет основу отладки.

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

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

Цель проверяющего (тестовика) — заставить программное обеспечение сбиться. Он доволен, если это ему удается.

Если программное изделие правильно ведет себя для солид­ного набора тестов, нет оснований утверждать, что в нем нет ошибок. Просто неизвестно, когда оно не сработает и можно говорить лишь о некотором уровне уверенности в его правиль­ности.

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

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

Необходимо с самого начала не допускать ошибок в прог­раммном обеспечении. Тогда роль тестирования будет состоять в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированном программном обеспечении.

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

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

Тесты составляются после разработки алгоритма, но до программирования.

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

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

В некоторых случаях тестирования рекомендуется производить «миниатюризацию» программы, т.е. разумно сокращать объём данных по сравнению с реальным. Например, создать укоро­ченную базу данных. Проверить матрицу 50x50 вручную невоз­можно. Поэтому в качестве теста может быть использована матрица 5x5. Точно так же, если некоторая подпрограмма рабо­тает в цикле 5 раз, она сможет работать и 105 раз. Правда, при миниатюризации программы могут произойти ситуации: либо существующие в программе ошибки в результате упрощающих изменений станут неявными или временно исчезнут, либо поя­вятся новые ошибки.

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

В целом составление тестов — большое искусство, т.к. пол­ностью этот процесс формализации не поддается.

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

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

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

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

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

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

Для ускорения отладки не безразличен порядок пропуска тестов: сначала пропускаются простые тесты...

Простые тесты проверяют начальную цель тестирования - работает ли программное обеспечение вообще.

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

Усложнение тестовых данных должно происходить посте­пенно.

Процесс тестирования программного обеспечения можно разделить на три этапа:

  - проверка в нормальных условиях;

-   проверка в экстремальных условиях;

-   проверка в исключительных ситуациях.

Каждый из этих трех этапов проверки должен гарантировать получение верных результатов при правильных входных данных и/или выдачу сообщений об ошибках при неправильных входных данных.

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

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

Типичные примеры — очень большие числа, очень малые числа или отсутствие информации.

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

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

Программное обеспечение должно самоотвергать любые дан­ные, которые оно не в состоянии обрабатывать верно.

Различают еще так называемые «Альфа»- и «Бета» - тестирования.

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

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

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

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

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

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

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