на тему рефераты Информационно-образоательный портал
Рефераты, курсовые, дипломы, научные работы,
на тему рефераты
на тему рефераты
МЕНЮ|
на тему рефераты
поиск
Программа регистрации процесса производства для автоматизированной системы управления предприятием электронной промышленности
b>4.6 Эволюция

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

добавление нового класса или нового взаимодействия между классами;

изменение реализации класса;

изменение представления класса;

реорганизация структуры классов;

изменение интерфейса класса.

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

4.7 Сопровождение

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

Типичный порядок действий на этом этапе таков:

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

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

если позволяют ресурсы, планируют в следующем релизе менее интенсивные, более локализованные улучшения;

приступают к разработке следующего эволюционного релиза программы.

4.8 Заключение

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

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

5. Методика отладки и результаты работы программы

5.1 Особенности тестирования программных продуктов

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

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

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

невысокая степень формализации критериев качества процесса тестирования и достигаемого при этом качества программного обеспечения как объекта тестирования;

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

Неоднократно экспериментально установлено, что в любом сложном программном обеспечении в процессе эксплуатации обнаруживаются ошибки, даже если проведено самое тщательное тестирование. Тем самым объективно утверждается, что невозможно формализовать и обеспечить абсолютную полноту всех эталонных значений, а также провести всеобъемлющее исчерпывающее тестирование и гарантированно устранить все ошибки в сложных программных продуктах. Поэтому тестирование проводится в объемах, минимально необходимых для проверки программ в некоторых ограниченных пределах изменения параметров и условий функционирования. Ограниченность ресурсов тестирования привела к необходимости тщательного упорядочения методов и конкретных значений параметров с целью получения при тестировании наибольшей глубины проверок программ. Анализ многих проектов показывает, что до начала тестирования число ошибок в сложных программах составляет порядка 1-2% от общего числа объектных команд в программе, т.е. в программном обеспечении объемом 100 тысяч команд в процессе тестирования обычно выявляется 1-2 тысячи ошибок. При тщательном системном проектировании и программировании на языках высокого уровня начальное число ошибок в несколько раз меньше. Таким образом самое тщательное тестирование сложных программных комплексов позволяет получить программы с вероятностью ошибки в каждой команде порядка 10-4-10-5, т.е. несколько ошибок может остаться не выявленными.

5.2 Типичный процесс тестирования программного обеспечения

Процесс тестирования программ обычно включает:

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

статическое тестирование текстов разработанных программ и данных на выполнение всех заданных правил построения и описания без исполнения объектного кода;

тестирование программы с её исполнением в объектном коде и с разными уровнями детализации: детерминированное, стохастическое, и тестирование в реальном масштабе времени;

диагностику и локализацию причин отклонения результатов тестирования от заданных эталонных значений и правил;

разработку изменения программы с целью исключения причин отклонения результатов от эталонных;

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

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

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

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

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

5.3 Особенности задачи в приложении к тестированию программ

5.3.1 Особенности среды программирования

Среда программирования Microsoft Visual Studio 6.0 и язык программирования в ней Microsoft Visual C++ имеют ряд особенностей, влияющих на тестирование программ:

Visual C++ является языком программирования высокого уровня, что сильно увеличивает значимость статического (символьного) тестирования;

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

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

в комплект Visual Studio входит множество утилит для отладки, значительно облегчающих процесс тестирования программного обеспечения;

большую часть структуры программы в Visual C++ with Microsoft Foundation Classes занимают стандартные, автоматически создаваемые объекты, управляющие работой программы в ответ на действия пользователя. Поэтому ошибки в основном содержатся в алгоритмах процедур, написанных программистом.

5.3.2 Основные факторы, влияющие на надежность разрабатываемой системы

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

корректность структуры программы;

корректность обработки данных;

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

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

недопустимо непустое значение поля данных;

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

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

5.3.2.1 Контроль структуры программы

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

Суть критерия состоит в выборе и анализе базовых маршрутов в программе, формируемых и оцениваемых на основе определения цикломатического числа исходного графа, определяющего структуру программы или ее фрагмента. Критерий наиболее широко применяется для оценки сложности и корректности тестирования программных модулей. Для определения цикломатического числа Z исходного графа фрагмента программы используется полное число его вершин Nп, связывающих их дуг Y и связных компонент L: Z = Y - Nп + L. Вычисление цикломатического числа осуществляется по величинам, определяемым по максимально связному графу, который получается из исходного путем замыкания дуги из конечной вершины в начальную. В результате в максимально связном графе появляются маршруты между любыми двумя вершинами. При этом предполагается, что исходный граф корректен, т.е. не содержит "висячих" и "тупиковых" вершин. В таком графе цикломатическое число равно максимальному количеству его линейно-независимых маршрутов. Величина L соответствует количеству связных компонент всего исходного графа, и обычно для графов не содержащих полностью независимых частей L=1. Иначе говоря, L измеряется количеством замыкающих дуг, необходимых для преобразования исходного графа в максимально сильно связный граф.

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

Рис.16. Фрагмент исходного текста программы

Рассмотрим на примере фрагмента кода разрабатываемого программного обеспечения тестирование корректности структуры этого фрагмента (см. рис.16). На основе данного фрагмента кода выделим операторы управления и построим графовую модель программы по управлению. Цифрами на рис.16 условно обозначены вершины графа. Рис.17 отображает схему этого графа.

Рис.17. Граф программы по управлению

Далее определим цикломатическое число графа по исходным данным:

Nп = 6

Y = 8

L = 1

Z = Y - Nп + L = 3

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

Рис.18. Линейно-независимые маршруты

В итоге для проверки корректности структуры данного фрагмента кода необходимо провести статическое и динамическое тестирование четырех полученных маршрутов.

5.3.2.2 Контроль чтения и записи переменных

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

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

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

существует ли запись этой величины вообще;

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

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

Рис. 19. Схема контроля чтения и записи переменных

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

Страницы: 1, 2, 3, 4, 5, 6, 7


© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.