Характеристики языков psl и rsl
RSL имеет: 19 типов объектов, 20 отношений и 20 атрибутов.
Объекты разных типов могут иметь частичное пересечение типов объектов. В RSL имеет смысл выделить такой объект как структура, на основе которой может формироваться R - сеть, обеспечивающая последовательное выполнение определенных данных и реализацию в таком технологическом комплексе, как альфа.
Прототипирование, как метод определения требований к ПО
В начале 80-х годов появился новый подход к формальному определению требований к будущему проекту, который назвали быстрым прототипированием, суть которого состоит в том, что если при традиционном подходе результатом определения требований является описание содержательных функций будущего проекта их взаимосвязей и обработка данных, то в новом подходе результатом формирования требований является действующий программный продукт или прототип в ряде случаев называемый макетом, создаваемой системы, который может иметь не совсем привлекательные черты с точки зрения оптимального продукта, он может быть несовершенным программным продуктом, в ряде случаев работающий очень долго, но позволяющий оценить и сориентировать будущий программный продукт в нужном направлении.
Отличие подходов состоит в том, что при традиционном подходе не соответствие описания требований к системе программного обеспечения реальным потребностям обнаруживается лишь на этапе завершения реализации проекта. В результате такого несоответствия возникают неприятные ситуации. Для того чтобы программное обеспечение или будущий проект сориентировать требуются достаточно большое время и средства.
Для ряда проблемных областей вероятность несоответствия высказывания пользователя вносит существенный характер в процессе автоматизации, т.е. если бы процесс был автоматизирован, то информация поступающая от пользователя носила бы либо формальный, либо неформальный характер, что всегда бы увеличивало сроки и средства вкладываемые в разработку. При автоматизации новой деятельности, проблемной области пользователь не всегда имеет обоснованное представление о функциях системы, поэтому начало автоматизации немедленно изменит представление пользователя о системе. Пользователь часто не в состоянии оценить будущий проект, поэтому автоматизация процесса формирования требований носит необходимый характер в процессе разработки системы ПО.
Лекция 12
Технология программирования
Существуют приложения, в которых использование метода прототипирование не допустимо.
1) Система жесткого реального времени, в котором не эффективность или возможная ошибка приводит к аварии объекта, который описывает наш прототип. Например – управление ракетой, управление в ядерной отрасли.
Прототип (макет) – быстрореализуемая по минимуму программных средств, не эффективная (небрежно реализованная) система, но позволяющая понять, оценить и осознать будущий проект вашего прототипа, оценить его возможности, понять возможности будущего прототипа. Ускорение разработки проекта увеличивает в 7,10 раз, например задача 7 лет прототип или год.
В этом прототипе проводится полное игнорирование эффективности программ, используются как правило простые методы ( ПО возможности используются выразительные средства).
Метод прототипирования возник только тогда, когда появились некоторые выразительные возможности описания алгоритмов, т.е. в 80-х годах этот метод не применялся из-за средств.
Один из таких языков, язык SETL. Этот язык появился при разработке программных систем в технологических комплексах. Другим языком тог же направления является язык NOMAD, который явился классическим представителем такого направления. Он широко распространен и носит название – метод быстрого проектирования или прототиапрования, предназначен для разработки программ и систем программного обеспечения и используется обычно в сфере экономки и управления производством. Для данной области обычно характерны отсутствие у будущих пользователей понимания проектов, оценки требований к программному обеспечению. Заказчик и пользователь не могут часто определится, какой программный продукт им нужен.
Язык NOMAD является языком 4-го поколения и объединяет в себе технологию процедурных и не процедурных языков. Он содержит в себе ряд обычных языков и включает в себя системы управления базами данных. Язык NOMAD высоко интерактивен и позволяет использовать режим команды в любом из указанных режимов, процедур, позволяет расширять систему команд. Пользователь языка NOMAD может, применяя простые команды выполнять разнообразные действия по формированию различной сложности отчетов, таблиц, графиков, определять и изменять структуру базы данных, обновлять ее, генерировать статистические. данные базы данных. Существуют проблемы, которые продиктованы языком NOMAD. Он не дает эффекта в конкретных проблемных областях, т.к. он не имеет выразительных средств, позволяющих кратко и понятно описать определенные (базовые) термины проблемной области. Для этого существуют другие языки. которые адекватно отображают понятия предметной области. Например: язык PROLOG, который подходит для проблемных областей связанных с логическим оформлением результатов. Проблемная область здесь некоторая математико-логическая область. В ряде технологических комплексах RADA, ARGUS в них есть язык прототипирования RРL, который не в большей степени зависит от проблемной области и представляет пользователям средства для проектирования, ориентирования на конкретную область программирования. Язык RРL имеет некоторые свойства – язык сильно расширяющий, очень высокого уровня. Пользователь может включить в язык проблемно - ориентированные типы данных, связать их с системой, подцепить к ним определенные действия и сформировать систему разработки, которая носит название среды RPL. Он может:
1) добавлять новые типы данных
2) вводить операции над объектами новых типов
3) определять взаимодействие объектов
4) определять приоритеты операций
5) вводить новые типы констант.
Псевдокоды
Псевдокодами называются полностью формализованные языки, которые на равнее с обычными программными языками позволяют включать в описание проекта программы. фразы на естественном языке разработчика.
Эти фразы рассматриваются на содержательном уровне и как правило описывают те элементы проекта, которые в настоящий момент не удается формализовать.
Появление псевдокодов или появление не формализованных средств описания объекта вызвано тем, что для сравнительно больших и тем более сложных программ практически сразу не возможно создать программу. Она создается постепенно там, где алгоритм понятен, проект реализуется, там где формальное описание невозможно вставляются вставки описывающие содержимое данной части проекта, т.е. нужны средства, которые фиксируют состояние проекта в текущий момент. Первоначально для таких проектов используется метод блок-схем, который на определенном уровне помогал увидеть проект в целом. Однако при увеличении сложности проекта и переводе его в плоскость программирования, проект становился не осознаваемым. Альтернативой этому и появились псевдокоды, в которых появились изобразительные средства, стимулирующие разработку проекта ПО в стиле структурного программирования. При таком подходе в противовес блок-схемам предполагалось использование ограниченного числа унифицированных элементов, обеспечивающих определенный уровень автоматизации разработки проекта. В основном псевдокоды используются на этапе детального проектирования, для разработки модулей программы методом пошаговой детализации. Применение этого метода поддерживается тем, что в текст программы вводится некоторые нормативные неформальные описания, которые и являются уточнением данного блока программы.
Поскольку псевдокоды частично формализованное. средство для описания проекта, то многие детали могут быть описаны в любом формальном или неформальном языке, понятный ему и группе разработчиков, в которую он входит. Это в свою очередь порождает проблемы, не позволяющие провести полную автоматизацию проекта, т.е. процесс обработки автоматизации текста в данных языках не разработан. Он проводится только ручным способом. Для решения этой проблемы предполагается использовать псевдотерминальные среды (оболочки) примером такой среды является экспериментальная тотальная автоматизация программирования (STAP) в ней включены 1) псевдокоды
2)терминальные языки
3) псевдотерминальный язык кант.
Псевдотерминальный язык является полностью формализованным и в отличие от терминальных языков (Фортран, Бейсик, СИ и тд.) позволяет использовать структуры управления и данных языка. При таком подходе невозможно приспособится к конкретной проблемной области. Зато обеспечивает автоматизацию самого процесса пошаговой детализации, где учитывается связь объектов между собой и программой, где в качестве языка псевдокода может использоваться любой процедурный язык.
RD - технология (рассредоточенное действие)
В основе RD - технологии лежит основополагающая концепция Фуксмана: сосредоточенное описание , рассредоточенных действий.
Эта концепция реализована в технологии вертикального слоения и развивает технологию вертикального слоения в 2-х направлениях.
1) Распространяет использование принципа Фуксмана на реализацию расширяющих функций и на любые рассредоточенные функции т.е. функции, реализация которых не может быть представлена виде связного программного текста.
2) вводится понятие RD - модуля или модуля рассредоточенных действий, который обобщает вертикальный слой Фуксмана и наделяет его главным атрибутом классического модуля - это автономное проектирование, его познаваемость разработки и тестирования, т.е. все те свойства, которые принадлежат обычному программному модулю, также и этап отладки.
Проблема представить реализацию рассредоточенной функции и как следствие препятствует адекватному изображению или адекватному разбиению программы на функционально - прочные модули, приводит к нарушению свойств слабой связанности по данным т.к. использование абстрактных типов данных обслуживающих реализацию рассредоточенной функции также оказывается рассредоточенным по тексту программы (по различным ее модулям). Наиболее приемлемое решение этой проблемы представляет технология вертикального слоения, которая основана на вертикальном слоении Фуксмана. Эта проблема решается на основе RD –модуля, в который вместо громоздкого контекста вертикального слоя используется компактная и познаваемая модель, играющая важную роль как при отладке как и при тестировании модуля. а также позволяет объединять и связать RD - модули в единый программный проект. RD - модули предназначены для адекватного описания рассредоточенных функций, обобщающих традиционные формы модульности и являются развитием и конкретизацией сосредоточенного описания рассредоточенных действий.
RD - модуль представляет собой последовательность разделов:
1) тело
2) интерфейс
3) локлы
4) импорт
5) интеграция.
Тело RD -модуля – объединение моделей с именами действий, реализующих рассредоточенные функции.
В разделе интерфейса, содержится описание интерфейса по данным между вершинами и действиями RD -модуля.
График
В разделе локалы находится описание данных, необходимых для реализации действий RD - модуля и указания координат их вставки в фоновую программу.
В разделе импорт содержатся имена глобальных данных и имена программных единиц из которых они импортируются.
В разделе интеграция включается информация, не относящаяся непосредственно к реализации RD – модуля, но необходимая для автоматизации и интеграции RD- модулей в будущем программном проекте.
Концепция RD - модуля и RD - системы приводит нас к технологии RD, которая состоит в регулярном прагматическом применении при разработке программного изделия, основополагающего принципа Фуксмана: Сосредоточенное описание, рассредоточенных действий, RD - технология в совокупности с другими технологиями может применятся на всех этапах разработки программного изделия, начиная от проектирования верхнего уровня вплоть до этапа тестирования кода программы, отладки программы.
Лекция 13
Технология программирования 8.04.08г.
Структурное программирование предложено разработчиком Дейкетрой. Основная идея которого положена в основу метода структурного программирования - понимаемость программы. В основа такого идеологического метода показывает то, что программа включает ряд подходов, нисходящее проектирование, ограниченное число исполнительных программных конструкций, модульность и др. эффекты. Структурность таких методов и носит название структурного подхода, в котором реализуется основная и идеология 3-х видов операторов: последовательный, условный и оператор цикла. Доказано, что этих 3-х операторов для представления программы сверх вниз достаточно. Основным нарушителем данного подхода по Дейкетру является оператор goto, который можно и не исполнять.
Однако существуют операции, когда нужно и лучше его использовать.
Второй момент в структурном подходе. возможность некоторой автоматизации и унификации программы, т.е. использование блочного программирования (один вход и выход), а с другой стороны возможность использования ограниченного числа операторов. Это позволяет:
Понимать программу.
тестировать ее
программа начинает становиться прозрачной и не зависеть от объема.
Метод Джексона
Построение программы от данных
Который ориентирован на разработку хорошо структурированных, читаемых программ обработки данных сложной структуры. Здесь под сложностью структуры данных понимается сложность их логической организации, иначе говоря интерпритации данных, но несложность структуры их организации в плане хранения, записи и считывания.
Процедура создания программы по методу Джексона состоит из следующих шагов:
1) Проектирование программы начинается с описания содержательной структуры. Проблемы, в том числе входных и выходные данные представлены в виде графических диаграмм или эквивалентного представления их в виде псевдокода. Если структура входных и выходных данных очевидна, то она как правило не описывается, а сразу вписывается в систему.
2) Выявляется соответствие между компонентами программы и их описания входных и выходных данных. В случае если структура входных и выходных данных хорошо согласовывается между собой, то мы переходим на следующий шаг разработки программы.
В случае. когда возникают конфликты типа когда входные и выходные данные конфликтуют между входными и выходными данными, когда не удается построить структуру, соединяющую входные и выходные данные, тогда эти этапы переносятся на следующие этапы и разбираются отдельно.
3) Определяется полный перечень действий, которые должны быть выполнены при обработке компонентов структур данных. Надо выявить все способы описания данных, позволяющих обеспечить формальную полноту проблемной области.
4) Действия по обработки данных включаются в соответствующие позиции диаграмм описания данных в результате чего эти данные превращаются в диаграмму обработки данных.
5) Стереотипным образом диаграммы обработки данных преобразовываются в программы обработки данных на некотором языке программирования.
Метод Джексона исполняет также 3 вида операторов: последовательный, ….. , альтернация (послед. условный, цикла)
Конфликты, возникающие при структуризации входных и выходных данных в методе Джексона
1) Конфликт порядка
2) Конфликт структур
1) Конфликт порядка - это такой конфликт, когда совмещение структур разных описаний невозможно из-за различия следования или порядка следования некоторых двух компонентов одного и того же описания и соответствующих им компонентов другого описания.
2) Конфликт структуры – ситуация в которой в 2-х различных описаниях нет соответствия между компонентами типа итерации, в то время, как подчиненный им компоненты соответствуют друг другу, т.е. возникают 2 структуры.
График
R – технология
разработана в институте им Глушкова и является типичным представителем методов использующих графические средства представления данных при разработке программного обеспечения. В ее основу положены 3 фундаментальных принципа.
1) В качестве изобразительного средства описания программы предлагается язык нагруженных ориентированных графов.
2) Построение программы, осуществляется от данных, т.е. вначале на языке графов описываются данные, а затем полученный граф доопределяется до алгоритма обработки.
3)Разработка программного обеспечения выполняется по безбумажной технологии под управлением и контролем со стороны ЭВМ. Применяемый в R- технологии язык – это язык графов с нагруженными дугами, каждая дуга графа может сопровождаться произвольным текстом сверху вниз. Текст под дугой определяет условия прохода по дуге. а текст над дугой определяет действия, которые производятся в данном направлении….
Вершины графа соответствуют состоянию программы из каждой вершины может выходить и в каждую может входить по несколько дуг. Для улучшения качества создаваемого программного обеспечения в R - технологию вводятся ограничения на способы построения программ. Для чего вводятся структуры (подграфы) с одним входом и одним выходом, подобная идеология уже реализована в UNIX - подобные и в ряде языков, например, FORD.
Граф. представленный в таком виде и представляет собой объединенный граф R - технологии, и который уже можно применять весь математический. аппарат.
При создании технологических комплексов, поддерживающих работу метода R –технологии, были предприняты значительные усилия по ослаблению проблемы плохой стыкуемости программ, т.е. при производстве описания программы независимые разработки часто не могли состыковать свои конструкции и схема была часто неразрывной и не стыкуемой. Работая в таком стиле возникает проблема, когда часть одной группы не соответствует части другой группы. Если бы ни эти нестыковки процесс автоматизации был бы очевиден, для решения этой был разработан специальный математический аппарат учитывающий технологический подхода псевдокода, когда на стыкуемых площадках R – технологии конфликты разбирались отдельно предметниками и математиками. Переход на автоматизированную работу с графической формой записи, а именно это предложили математики, позволил ввести в построение программы такое понятие, как чертеж и появление связанной с ним дисциплины – чертежное проектирование
Чертеж в методы R - технологии используется как единица разработки и как единица документации, т.е. единая и не делимая часть будущей программы.
Рабочее поле чертежа содержит формальное описание данного этапа программы (результата шага программы).
Язык R – схем
Представляет собой некоторую оболочку, в которой может быть погружен любой язык, т.е. как формальный, так и не формальные языки, т.е. в качестве нагрузки могут использоваться логические выражения и операторы любого погружаемого языка в эту оболочку в том числе и естественного языка. Например, в Глушко использовали Фортран, Алгол и в том числе и русский язык.
Наиболее важным принципом R - технологии является применение сквозной автоматизации на всех технологических этапах разработки программы по безбумажной технологии (схеме), с автоматизацией управления организационной деятельности коллектива разработчиков, распределение работ, и контроль, за качеством их выполнения. Разработки программного обеспечения по R - технологии осуществляется, как некоторый регламентированный процесс по запоминанию заранее заготовленных или автоматически сгенерированных технологических шаблонов.
Лекция 14
Анализ правильности проектной информации.
На всех этапах развития и разработки программного обеспечения необходимо представление как программы, так и документирования
1) Проблема: как адекватно считать информацию достоверной.
Существуют всевозможные стратегии в плане выбора проектной информации
Тестировщик
Методы и информация
Основные проблемы и виды анализа проектной информации. Этапы жизненного цикла разработки Программного обеспечения можно понимать, как процесс тестирования или процесс преобразования одного вида информации в другой. Если перед первым этапом стоит проблема, как объединить или сбалансировать интересы пользователя и разработчика, то на втором тестирование, поиск ошибок, достоверной информации о программе. Чем раньше обнаружена ошибка в проектной информации, тем меньше потребуется труда на ее исполнение. Поэтому проверка правильности проектной информации должна рассматриваться не только, как процесс завершающий каждого этапа, но и рассматривается, как вид деятельности заключающий в себя все этапы этой фазы, т.е на каждом этапе, такая деятельность как проверка присутствует и необходима. Главная проблема, с которой сталкивается разработчик при попытке анализировать правильность проектной информации заключается в том, что универсальных и исчерпывающих методов анализа нет или не существует. Для нас очевидно, что исчерпывающими методами анализа проектной информации на ее правильность могут быть формальные методы, т.е аналитические.
Существуют 2 класса таких подходов:
1) Основан на извлечении правильной информации из математических рассуждений в частности из программ.
2) Опирается на доказательство правильности заданной проектной информации.
Оба подхода базируются на принципе –Вся исходная(входная) информация достоверна. И поэтому проблема проверки правильности проектной информации сводится к проверке правильности исходной информации.
Существует ряд недостатков формальных методов проверки информации:
1) Сложность, громоздкость и как следствие этого внесения, появляется множество ошибок.
2) Невозможность прогнозирования функционального программного обеспечения в случае не верных входных данных.
3) Практическая невозможность учета ограничений машинной арифметики.
4) Отсутствие методов, позволяющих работать с такими языковыми средствами как, например, параллелизм сложных структур, когда структура сложная, но вход и выход одинаков.
Формальные методы анализа правильности проектной информации интенсивно развивающиеся и применяющиеся на практике разработки небольших проектов или для проектов специальной прикладной области в которой удается реализовать , хотя бы частично некоторые параметры.
Конечной целью развития функциональных методов является переход в автоматизированный процесс проверки правильности информации. В настоящее время формальные методы подходят в направлении верификации правильности проектной информации на основе интуитивных предположений, разработанных Флоидом и модифицированными Хоаром. Именно они перспективны в процессе автоматизации. Суть метода: Метод интуитивных предположений.
Состоит в рамках некоторой формальной логической системы(исходные утверждения) формулируются утверждения о входных и выходных данных программы в точках расположенных перед началом и концом определенных вершин графа(управляющего графа) двигаясь от начальной вершины графа по управляющему, осуществляется преобразование входных данных или исходных утверждений в зависимости от направления движения в графе. В результате этого процесса имеется 2 утверждения для одной и той же точки управляющего графа. Исходные утверждения, полученные в результате преобразования ,затем формируется теорема о том, что из выведенного утверждения следует исходное. Успешное доказательство этой теоремы свидетельствует о том, что управляющий граф построен правильно, кроме того, доказывать требуется также, что программа завершает свою работу в логике управляющего графа. Обычно формируется не одно условие верификации , а несколько в соответствии с маршрутом управляющего графа.
В случае цикличности, а в каждой программе их много, разбирается отдельно поток и прикладывается как приложение к управляющему графу. Рассмотрение отдельно этих циклов существуют отдельные самостоятельные методы, проверяющие внутреннюю структуру цикла(анализ самостоятельного внутреннего поведения). Перечисленные выше трудности применения формальных подходов, приводят к необходимости использовать в большинстве случаев эмпирические походы (неформальные), т.е в основе методов лежат испытания проектной информации с целью найти в них ошибки, но не подтвердить их. Среда неформальных методов , в первую очередь следует отличить тестирование, , которое представляет собой процесс выполнения программы с намерением найти ошибку. В процессе тестирования вырабатывается набор текстов( исходные данные , производиться запуск или серия запусков тестов, а результаты полученных тестов сравниваются с их эталонными значениями, например в измерительных комплексах.) Существуют различные стратегии тестирования, однако, все они нацелены на выбор оптимального набора тестов. Под оптимальностью будем понимать компромиссное между полнотой тестирования и количеством тестов. Т. е. иначе говоря, тестирование по своей природе не может быть исчерпывающим. Более того , тестирование относится к категории экономической, поскольку невозможно запустить неограниченное число тестов. Например, прототипирование, представляет собой тоже разновидность теста, связанное с начальным этапом тестирования будущего программного проекта , поскольку именно на нем проверяются знания и сбалансируются интересы 3х сторон, заказчик-пользователь-разработчик. Тестирование относится к динамическим средствам проверки правильности проектной информации , т.е средством основанном на выполнении (реальный или имитирующий процесс). К динамическим средствам можно отнести:
1) Проверка программы в процессе выполнения утверждений , выполняемых в программе, в вычислениях , в выявлениях промежуточных точек, значениях в них.
2) избирательность выявления значений в процессе тестирования программы.
К динамическим методам тестирования можно отнести символьное тестирование , символьное выполнение программ, суть которых состоит в том, что в процессе выполнения результаты программы получаются преображения в виде символьных образов выходных значений. Преимущества данного подхода по сравнению с тестированием состоит в том, что один прогон программы эквивалентен ряду прогонов программы тестирования, т.е если при обычном тестировании одной области а, в должен каждой точка прогнать, то в символьном лишь область ав., поэтому символьные программы занимают промежуточную нишу между формальными методами и империческими методами. Символьное тестирование относится к динамическим методам, а верификация к статическим, кроме того к статическим методам относится и ряд других формальных методов, которые отвечают за полноту и замкнутость программы, т. о методы оценки проверки правильности информации рассматривается по 3м направлениям:
1) Статическое или динамическое
2) Формальные или неформальные
3) Ручные или автоматизированные.
Кроме проблемы выбора адекватных методов проверки правильности проектной информации и их программной поддержки существует еще ряд проблем проверки этой информации.
1) Это проблема воспроизводительности,, т.е проверка повторяемости полученных результатов.
2) Управление деятельностью по проверке проектной информации.
3) Проблема выбора категории лиц, осуществляющих эту проверку.
4) Проблема определения или обеспечения полноты проверки, определения планирования процесса проверки.
Тестирование программного обеспечения и его составные части.
Основное назначение тестирования не в демонстрации отсутствия ошибок, а ее работоспособность, поэтому тестирование понимается как процесс исполнения программы с целью обнаружения ошибок. Практика разработки Программного обеспечения выделяет 2 стратегии поиска ошибок.
1) Стратегия черного ящика.
2) Стратегия белого ящика.
Стратегия черного ящика или тестирования по данным (по входу и выходу )игнорирует внутреннюю структуру программы и анализ базируется на данных входа и выхода. Целью тестирования является выявление обстоятельств, при которых поведение программы не соответствует ее спецификации. При таком подходе обнаружение всех ошибок возможно лишь при исчерпывающем тестировании, те. тогда когда в набор теста входит бесконечное число наборов входных данных на практике это никому не удавалось и появились , понятия -результативный тест, который осуществлялся числом ошибок получающихся в результате однократного прогона программы. Это влечет за собой понятие эффективных тестов, т.е такого подмножества всех возможных тестов ,которые имеют наивысшую вероятность обнаружения большинства ошибок в программе. Для получения эффективности тестов разработан ряд методов:
1) Эквивалентное разбиение
2) Анализ граничных значений
3) Функциональные диаграммы
4) гипотеза ошибок
1)Метод эквивалентных разбиений состоит в разбиении входных данных (входной области) на конечное число классов эквивалентности, при которых каждый тест некоторого класса эквивалентен в смысле обнаружения ошибок любому другому тесту этого класса. Разработка методов эквивалентного разбиения осуществляется в 2 этапа
1) Выделение эквивалентных классов
2) Построение теста на этом классе.
Классы эквивалентности: выделяются на основе анализа входной области и спецификации программы. При этом различают 2 класса эквивалентности правильный и неправильный.
1) О законах непрерывности данных
2) Непрерывной
При построении эквивалентных областей используется следующая последовательность действий
1) Каждому классу эквивалентности назначен уникальный номер.
2) Из множества правильных тестов выбирается тот, который накрывает наибольшее число классов эквивалентности
3) Для каждого неправильного класса эквивалентности вырабатывается отдельных индивидуальный тест
2) Метод граничных значений
Метод, дополненный до проверки на границе области.
Главным недостатком методов эквивалентного разбиения и граничных значений является то, что они не могут рассмотреть комбинации входных условий.
3) Метод функциональных диаграмм
Метод был разработан фирмой IВМ и представляет собой оценку причинно-следственных связей, где входными данными являются причины, а выходными- следствия. Метод функциональных диаграмм представляет собой формальный язык, на котором транслируются спецификации, написанные на естественном языке.. Построение тестов осуществляется в несколько этапов для уменьшения громоздкости и трудоемкости, спецификация разрабатывается на рабочем участке в каждом рабочем участке , определяется причины, которые характеризуют отдельное входное условие или определяют некоторые остаточные действия программы. Каждой причине и следствию присваивается отдельный номер. Причинно- следственные отношения отображаются в виде булевого отношения или графа с двумя узлами и дугой, где под дугой понимаются логические условия «и» , «или», «не». Полученный граф и получит название функциональной диаграммы, Ограниченные и синтаксически невозможные комбинации причин и следствия оформляются отдельно, как приложение к функциональной диаграмме и рассматриваются самостоятельно.
Лекция 15
Методы функциональных диаграмм
В особых ситуациях решения формируются отдельно и рассматриваются после формирования тестовых решений, т.е оформляются в виде приложений к методу функциональных диаграмм.
В процессе прослеживания решений, состояния решений преобразуется в некоторую таблицу, где столбцами служат тесты с ограниченными входами, т.е столбцы формируются в тесты, которые при оптимизации можно применять оптимальный объем или на неограниченный объем.
Метод гипотез и ошибок или тестирование с использованием интуитивного предположения о некотором списке ошибок, проявляются в особых ситуациях предметной прикладной области.
Стратегия белого ящика(анализ внутренней структуры программы или тестирование управляемого логикой программы, построена на анализе внутренних условий программы(структурных условий)). Эта стратегия предполагает, что программа полностью работоспособна и проведено исчерпывающее число тестирований.
Недостатки данного подхода.
1) По определению исчерпывающего тестирования невозможно провести.
2) Нет гарантии того, что программа соответствует своим спецификациям , т.е программа жестко следует спецификации.
3) В программе могут быть пропущены некоторые операторы и условия.
4) Исчерпывающее тестирование не может выявить ряд ошибок условного характера, т.е по абсолютной величине а-в<ε
|A| - |B| ≤ ε : A>0: B>0: |A-B|≤ ε
Особенности тестирования черного и белого ящика
Для черного ящика существуют одни критерии, построение высоко-результативного теста при множестве методов поиска ошибок.
Стратегия белого ящика
Метод один поиск всех маршрутов , а критериев несколько.
Следующие критерии:
1) Критерии покрытия операторов
2) Критерии покрытия решений
3) Критерии покрытия условий
4) Критерии решений –условий
5) Критерии комбинаторного покрытия, т.е критерии белого ящика определяет покрытия логики программы.
1)Критерии операторов- когда по операторам пройтись хоть раз
2) Критерии покрытия решений – более сильный метод, который также удовлетворяет критерию покрытия операторов ,согласно этому критерию, каждое направление перехода ,должно быть реализовано хотя бы 1 раз., т.е надо пройтись по переходам работы программы.
3) Критерии условий. Являются более сильными критериями, при котором выполняется требование « пройтись хотя бы однократно по результатам каждого условия». Иначе говоря, поскольку при данном критерии не всегда удается пройтись по всем операторам, то и указанное требование дополняется требованием, что в каждой точке программы хотя бы один раз было передано управление покрытия условий.
4)Это такой критерий, как и (3), только в тестах должны еще участвовать анализ решений.
5) Комбинированное покрытие требует такого числа тестов, которое позволяло бы хотя бы один раз пройтись по всем возможным комбинациям результатов условий в каждом решении.
Известны 3 метода предупреждения и выявления ошибок.
1) Выбор оптимальной технологии разработки программного изделия, поддерживаемой мощными инструментальными средствами, четко регламентированными действиями, процессом разработки Программного изделия, что, в конечном счете, позволяет избежать множества ошибок.
2) Метод проведения поэтапной разработки программного изделия, а точнее проверку состояния программного изделия в конце каждого этапа разработки его жизненного цикла позволяет обнаружить и локализовать ошибки до следующего этапа разработки.
3) Программно-целевой метод тестирования программного изделия, состоит в четкой ориентации тестов на конкретные цели тестирования каждого шага разработки, например ,цели: тестирование особых ситуаций, тестирование операционной памяти, тестирование загрузки.
Выбор способа сборки программного изделия из отдельных его модулей наиболее важный
этап тестирования целого программного изделия. Именно здесь определяется форма направления тестов модуля, типы средств использующихся при тестировании, порядок тестирования модулей локализации и направления ошибок.
Для решения поставленной проблемы выбора, для решения процессов- разработано 2 подхода
1) Монолитное тестирование
2) Пошаговое тестирование(может быть как восходящим, так и нисходящим).
Монолитное тестирование предусматривает проверку всей программы целиком(комплекс программ)
Пошаговое тестирование-каждый модуль последовательно тестируется и тестирование следующего модуля определяется выбранным последним тестированием, т.е порядок определяется пользователем.
Анализ двух указанных подходов(преимущества и недостатки)
1) Монолитное тестирование более трудоемкий процесс сравнительно с пошаговым.
2)При пошаговом тестировании ошибки в межмодульных интерфейсах обнаруживаются раньше, т.е сборка программы идет практически с 0.
3) При пошаговом тестировании менее трудоемка отладка и поиск ошибок, т.е локализация ошибок и внешних изменений не влечет за собой переделку всего модуля.
4) Качество тестирования при пошаговом подходе выше, чем при монолитном тестировании, поскольку при пошаговом тестировании модулей, все оттестируемые модули могут выступать в виде заглушек и не участвовать в трудоемкой разработке тестов.
5) Затраты машинного времени в большинстве случаев при монолитном тестировании как правило меньше , чем при пошаговом, т.к при монолитном тестировании выполняется отдельный модуль, который просто передает управление, тогда как в конце тестирование производится в полном объеме.
6) Монолитное тестирование создает хорошие предпосылки для распространения процессов тестирования.
В связи со слабой формализованностью описания требований к программному изделию и составлению пользовательской документации, наконец, отсутствие методологии написания тестов для проверки системы выделены 15 категорий тестов, обеспечивающих тестирование системы разработки программного обеспечения.
1) Тестирование удобств пользователя, т.е тестирование каждого пункта пользовательской документации.
2) Тестирование на предельных объектах
Цель: показать, что программа не может управлять максимальным объемом данных специфицированными в исходных требованиях, т.е в техническом задании прописан максимальный объем памяти 12 мб..
3) Тестирование на предельных нагрузках- проверка функциональности программного обеспечения в стрессовых ситуациях, т.е максимального объема информации в сжатые отрезки времени, например, в сетевом режиме вводится с нескольких мест информация в базу данных.
4) Тестирование удобства эксплуатации, когда человеческому фактору уделяется большое внимание. Эти тесты ориентированы в основном на выявление психологической совместимости проблем возникающих при работе программного обеспечения
5) Тестирование защиты, которое представляет собой систему проверок информации от несанкционированного доступа в систему. Цель состоит в том, чтобы построить такой тест, который позволял бы вскрыть недостатки системы и на них войти в систему.
6) Тестирование производительности или эффективности программного обеспечения.
Проверка характеристик программного обеспечения обусловленная временем отклика и пропускной способностью программного обеспечения, при определенной нагрузке, т.е в техническом задании, как правило задано конкретное время.
7) Тестирование требований к памяти, т.е необходимость проверить предельные объемы оперативной и внешней памяти ,в любой момент времени работы программного изделия.
8) Тестирование конфигураций оборудования, как правило, тестируемые системы является достаточно большими, и обладают достаточной адаптируемостью к любой конфигурации. Поскольку конфигураций достаточно большое число, то и тестирование должно учитывать и эти проблемы конфигураций.
Проблемы конфигурации- Тестирование на совместимость- оно необходимо тогда, когда в программное обеспечение вносятся существенные изменения. Производится модификация программного обеспечения и когда необходимо создать процедуры конверсии одни данные в другие программного обеспечения.
9) Тестирование удобств установки программного обеспечения- оно проверяет установку достаточно сложного программного продукта, на конкретные условия эксплуатации.
10) Тестирование надежности в настоящее время носит принципиальный характер и является важнейшим показателем разработки программного обеспечения.
11) Тестирование восстановления
Существует ряд программных систем:
Проверка восстанавливаемости программного обеспечения заключается в предварительном ,преднамеренном вводе определенной информации, обеспечивающей заведомо нереализуемые ситуации, в которых программное обеспечение попадает в состояния неадекватные нормальному поведению программы.
12) Тестирование удобств обслуживания, как правило, состоит из комплекса инструментальных средств, облегчающих сопровождения программного обеспечения. Это возможность получения данных, все те средства, позволяющие изучить более детально тестирование программного обеспечения.
13) Тестирование документации
Проверка пользовательской документации входит в комплекс тестирования программного обеспечения и является предметом инспекций проверяемых органов, как правило основные критерии- ясность и четкость понимания описываемых процессов.
14) Тестирование процедур: если программное обеспечение является некоторой частью подсистемы обработки данных большой системы, в которой имеются процедуры выполняемые человеком, то эти процедуры должны быть протестированы
Анализ: трудоемкость тестирования составляет от 20 до 60% от всего объема работ, причем львиная доля его составляет -выбор необходимой исходной информации для получения эталонных значений. Эта задача резко экспоненциально растет, когда речь идет о комплексном тестировании огромного объема маршрутов, когда необходимо протестировать предельные нагрузки на программное обеспечение. Нередкий случай ,когда ручная разработка тестов практически невозможна и специально создается и ……..позволяющая генерирование тестов.
Методы отладки:
Основная задача программиста состоит в том, чтобы его программа работала без ошибок, для этого существует 2 подхода
1) Не делать ошибок вовсе, когда основная нагрузка ложится на качество программирования, когда программист тщательно выверяет каждую часть своей программы.
2) Находить все сделанные ошибки, когда стиль программирования неаккуратный и вся нагрузка ложиться на поиск ошибок.
Лекция 16
Известны три источника ошибок в написании программы (с точки зрения анализа их распределения) – это алгоритмические ошибки или неверный выбор алгоритма решения задачи. Эти ошибки могут иметь наиболее серьезный характер впоследствии до полной переработки программы. К ним относятся: не учет или неполный учет данных, неправильное понимание структуры рассмотрения алгоритма, как неполного подмножества данных, данные, выходящие за пределы задач, не знание или неполное знание средств вычислительной техники, незнание команд ЭВМ, языковых средств, возможностей среды разработки.
Описки – уровень обидной ошибки, который определен в результате просмотра.
Основная задача программиста состоит в том, чтобы его программа работала без ошибок.
Классификация ошибок по их внутреннему содержанию.
Основные классы ошибок.
Отсутствие инициализации переменных .
Такая ошибка может долго не проявляться, до тех пор, пока не появятся случайные данные, активизирующие эту ошибку.
Этот вид ошибок связан, как правило, с оформлением переменных на локальном уровне.
Ошибки индикации – это наиболее распространенные ошибки, когда обращение происходит за пределами памяти.
Ошибки при передаче параметра – это второй наиболее распространенный класс ошибок, характеризующийся большим числом параметров, типов параметров. Последние очень разнообразны, что не подвергаются классификации.
Ошибки, связанные с формулировкой условий.
Арифметические ошибки – это большой класс ошибок, связанный с аварийными ситуациями: деление на ноль, выхождение за пределы объема.
Ошибки косвенного доступа.
Они появляются, как правило, при использовании в доступе указателей для связи между объектами.
Висячие ошибки.
Они так же связаны с использованием указателей и генерируют ошибки, связанные с динамическими переменными, т.е. с созданием и удалением объектов.
Ошибки синхронизации
Одна из наиболее трудно уловимых ошибок, как правило, связанная с параллельными процессами.
Исторические ошибки – ошибки, связанные с данными, которые мы изменяем.
Способы проявления ошибок или симптомы проявления ошибок.
Неверная выдача:
Когда программа, завершается, а результат не верен.
Когда программа завершается, но
Когда программа зависает, ее выполнение заканчивается, а никаких сообщений нет.
Программа завершается, и ее выдача соответствует ожидаемым результатам, прог, читаемых прог обработки данных сложной структуры. Здено хранимые данные испорченны.
Основной вывод.
Любое изменение программы, входных данных или используемой среды, или состояния среды, в которых оно разрабатывается, может привести к появлению или исчезновению симптомов ошибки.
Каждый случай проявления симптомов ошибки нужно исследовать до самого конца, стараясь восстановить то состояние программы, в котором указанный симптом проявился.
Методы, используемые при поиске ошибок.
(делят на 2 категории)
Аналитический подход, когда методы поиска ошибок построены на анализе входных или выходных данных, т.е. по форме объекта.
Экспериментальный подход, когда используются отладочные средства программы, которые позволяют через внутренние точки программы выявить ошибку.
В обоих случаях методы базируются на общей стратегии – стратегии отладки, когда от обратного прохождения программы (от результата ошибки) вы двигаетесь в обратном направлении к месту возникновения ошибок.
В аналитическом способе нагрузка ложиться на аналитические способности программиста.
В экспериментальном - на программу, когда она проверяет ошибки.
Золотые правила отладки.
Обнаружив симптомы ошибки, даже если они имеют мерцающий характер, никогда не списывайте на ошибку ЭВМ.
Доводите до конца расследование каждого симптома ошибки, никогда не заменяйте фрагмент программы, на который падает подозрение ошибки, другим фрагментом до выявления ошибки или истинной природы ошибки.
Обнаружив в ходе анализа ошибку, неверную часть программы, убедитесь в том, что именно она является источником ошибок через конкретные расчеты (ручные).
Помните, что любое изменение параметров программы и ее входных данных или выходных данных или среды разработки, в которой она выполняется может привести к исчезновению симптомов ошибки. Добивайтесь повторяемости результата, до выявления истинности или истинной природы ошибки.
Оценка качества разработки ПО.
Основные показатели качества ПО.
Под качеством будем понимать, совокупность свойств изделия, выражающие его существенную определенность или индивидуальность, т.е. такую совокупность свойств изделия, благодаря которым оно является именно этим изделием, а не каким другим.
Какие программы считать хорошими?
Многообразие пользовательских интерфейсов приводит к тому, что для ПО невозможно создать формальную систему требований к его качеству. В промышленности высокое качество достигается за счет контрольных средств, т.е. контроль проводится простым сравнением. ПО невозможно таким образом сравнить.
Отметим, что разработка ПО и его качественной среды начало оцениваться по аналогии с оценкой качества.
Используя данную методологию, которая применяется при оценке качества ПО: на каждом этапе жизненного цикла программное изделии сталкивается с проблемой слабой формализованности программного продукта его индивидуальности, слабая формализованность ПО, что в результате привело к отсутствию единой системы качества оценки ПО и как следствие отсутствие этой системы привело к низкому качеству большинства программных изделий.
Основные черты хорошего ПО.
Документируемость, под этой характеристикой объединяются требования к пользовательской документации , раскрывающей назначение программы, ее индивидуальной особенности, методы внесения изменений и т.д.
Основные требования к документации: ясность и полнота описания, удовлетворяющаяся с помощью всякого рода руководств, в том числе ГОСТ-ов.
Эффективность – это выполнение всех функций программного изделия при оптимальном использовании его ресурсов (оперативной памяти, быстродейственность процессора).
Надежность, которая является одной из основополагающих характеристик программного изделия.
Особое значение программное изделие приобретает тогда, когда оно функционирует в реальном масштабе времени.
С этой характеристикой связаны практически все циклы разработки.
4) Эффективность можно рассматривать как интегральную характеристику ПО
5) Специфицируемость –это интегральная характеристика качества ПО, которая включает в себя ряд компонент:
а) полнота, т.е. в спецификации должна присутствовать вся информация для полноты разработки ПО.
б) безопасность, требование безопасности формирования всей системы обеспечивает работу не только самой программы, но и системы в которой она формируется.
Проверяемость всех файлов показателями, требованиями, представленными в спецификации.
в) Осуществление требований на регламентированных технических средствах. (ЭВМ).
г) Понятность назначения ПО каждому специалисту, использующему это ПО.
д) Адаптируемость означает, что данное программное изделие может с минимальными изменениями работать в других конфигурациях машин, с минимальными затратами на эти изменения.
е) Мобильность или переносимость характеризуется степенью необходимых изменений или дополнений, а в отдельных случаях и изменений данного ПО на новые технические средства (ЭВМ).
ж) Совместимость – это возможность использования ПО совместно с другим программным изделием, как составную часть общего программного изделия.
з) Испытуемость означает возможность оценивать правильность работы ПО или функционирования его в условиях конкретной среды (в условиях разных технических средств, на разных операционных системах).
и) Стоимость, которая является интегральной характеристикой качества программного изделия. Чем выше качество, тем дороже ПО.
к) Измеряемость характеристика, означающая возможность оснастить ПО специальными программными средствами, позволяющими заменить его характеристики и непосредственно с помощью базового набора индекаторов оценить ту или инуб характеристику качества программного изделия.
л) Сложность программного изделия является интегральной характеристикой меры качества, которая оценивает трудоемкость ПО, вклячая и тестирование ПО
Проблема оценки сложности ПО сейчас активно развивается, поскольку стоимость является прямой зависимостью от сложности.
Следует выделить два основных показателя качества:
Сложность из-за практической значимости;
Сложность из-за своей каррелированности разного рода характеристик качества.