Эквивалентное разбиение
 Скачать 5.11 Mb.
|
|
9. Дайте определение схемы, перечислите схемы, которые используются при документировании ПО, и их назначение. Приведите пример какой-либо схемы и назовите группы символов, которые в таких схемах применяются. Схема - графическое представление определения, анализа или метода решения задачи, в котором используются символы для отображения операций, данных, потока, оборудования и т.д. Различают: схемы данных; схемы программ; схемы работы системы; схемы взаимодействия программ; схемы ресурсов системы. Схемы данных отображают путь данных при решении задач и определяют этапы обработки и применяемые носители данных. Схемы программ отображают последовательность операций в программе. Схемы работы системы отображают управление операциями и поток данных в системе. Схемы взаимодействия программ отображают путь активации программ и взаимодействий с данными. Каждая программа показывается только один раз (в схеме работы системы может изображаться более чем в одном потоке управления). Схемы ресурсов системы отображают конфигурацию блоков данных и обрабатывающих блоков, требуемую для решения задачи или набора задач.  На данном рисунке изображена схема программы. В таких схемах используются следующие группы символов: символы процесса, указывающие фактические операции обработки данных; линейные символы для указания потока управления; специальные символы. 10. Приведите пример и дайте пояснения редуцирования таблицы решений для какой-либо внешней спецификации. Таблица решений – внешняя спец. ПО, в которой отражены комбинации условий, выполняемых для входных данных и соответствующие этим комбинациям действия по преобразованию информации. Редуцирование таблицы решений – если есть 2 столбца, у которых перечень действий совпадает и которые отличаются только результатом условий Да и Нет в одной строке, то такие столбцы могут быть слиты в один. Пример: 1)Изначально
2) После редуцирования
11. Назовите нотации и приведите пример нотации для изображения структурных алгоритмов Под нотацией понимаются правила формализованного описания структуры системы, элементов данных и других ее компонентов с помощью схем, диаграмм, формальных и естественных языков. Например, в качестве миниспецификаций некоторые CASE-технологии используют таблицы решений. Правила построения такой таблицы и представляют собой нотацию. Виды нотаций: Простая блок схема ARIS eEPS BPMN Структурные алгоритмы можно изобразить с помощью блок схемы Блок-схема – нотация, предполагающая описание структуры алгоритма с помощью геометрических фигур с линиями-связями, показывающими порядок выполнения отдельных инструкций. Этот способ имеет ряд преимуществ. Благодаря наглядности, он обеспечивает «читаемость» алгоритма и явно отображает порядок выполнения отдельных команд. В блок-схеме каждой формальной конструкции соответствует определенная геометрическая фигура или связанная линиями совокупность фигур. 12. Дайте определение прочности модуля и приведите примеры модулей с разными классами прочности. Прочность модуля – это мера его внутренних связей. Чтобы определить прочность модуля, необходимо проанализировать выполняемую им функцию (или функции), с тем, чтобы решить, к какому из семи классов он относится. Классы эти специально определены для того, чтобы ввести количественную характеристику «доброкачественности» конкретных типов модулей. Модуль имеет три основных атрибута: он выполняет одну или несколько функций, обладает некоторой логикой и используется в одном или нескольких контекстах. 1. Прочность по совпадению. Между предложениями модуля нет устойчивых смысловых связей. Такая ситуация возникает, если повторяющуюся группу предложений программы оформляют в виде отдельного модуля и используют его в разных контекстах. Например модуль вычисления суммы может использоваться в разных контекстах, и в зависимости от контекста изменяется и смысл связей между предложениями модуля. Основная проблема с модулями такого класса – это необходимость тщательной проверки, не теряется ли смысл обработки данных при каждом новом использовании модуля. 2. Прочность по логике - при каждом вызове выполняется некоторая функция из набора функций модуля. Как следует из этого определения, прочный по логике модуль выполняет несколько функций, и требуемая в конкретный момент функция выбирается (определяется) вызывающим модулем. Пример: библиотека стандартных программ, реализующих численные методы. Основная проблема с модулями этого класса – это использование одного и того же сопряжения в разных программах. Правила этого сопряжения должны быть выдержаны как в вызывающей, так и вызываемой программах. 3. Прочность по классу – модуль выполняет несколько функций, отнесенных разработчиком к одному классу. Например: autoexec.bat. Обычно это первые или последние модули в программных комплексах, на которые возлагаются операции инициализирования и завершения. Для таких модулей основная проблема состоит в том, что они неявно связаны с другими модулями и при изменениях прочных по классу модулей часто возникают ошибки, когда эти связи не учитываются. 4. Процедурно-прочный модуль - усложняются изменения в модуле.Þ– выполняет несколько функций относящихся к одной функциональной процедуре решения задачи. Здесь единственная проблема состоит в том, что фрагменты программы, относящиеся к одной функции, могут быть не последовательными в тексте модуля, это процедурно прочный модуль, в котором все функции модуля связаны по данным. Те же проблемы, что и у процедурно – прочного модуля, но они менее острые, т.к. связь по данным в одной функции ускоряет связь предложений этой функции и их разрыв менее вероятен, а иногда невозможен. 5. Информационная прочность – модуль выполняет несколько функций над одной и той же строкой данных, но каждая функция представляется отдельным входом в модуль. 6. Функциональная прочность – это когда модуль выполняет одну функцию – это то, к чему следует стремиться при проектировании модульной структуры ПО. Информационно - прочные модули следует рассматривать как физическое соединение нескольких функционально – прочных модулей. Модуль может соответствовать описанию нескольких типов прочности. В этом случае принято его относить к высшему типу прочности, определению которой он удовлетворяет. 13. Дайте определение сцепления модулей и приведите примеры модулей с разными видами сцепления. Сцепление - мера взаимозависимости модулей по данным. Сцепление - внешняя характеристика модуля, которую желательно уменьшать. Независимые модули могут быть модифицированы без переделки каких-либо других модулей. Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 7 типов сцепления. Следует заметить, что у различных авторов могут быть некоторые различия в оценке сцепления. 1. Полностью независимые модули (СЦ = 0). Модули, не вызывающие друг друга и не использующие общих данных, не сцеплены и являются полностью независимыми. Чем больше информации о других модулях используется в них, тем менее они независимы и тем сильнее сцеплены. 2. Сцепление по данным (СЦ =1). Модуль А вызывает модуль В. Все входные и выходные параметры вызываемого модуля - простые элементы данных. 3. Сцепление по образцу (СЦ = 3). В этом случае модули ссылаются на одну и ту же глобальную структуру данных. Недостатком такого сцепления является то, что оба модуля должны знать о внутренней структуре данных. Если программист, сопровождающий программу, модифицирует структуру данных в одном из модулей, он вынужден будет изменить структуру данных также и в другом. 4. Сцепление по общей области (СЦ = 5). Модули разделяют одну и ту же глобальную структуру данных. В этом случае возможностей для появления ошибок при модификации структуры данных в одном модуле много больше. По изменениям, производимым в объявленных параметрах, сразу можно определить модули, на которые эти изменения повлияют. Если модифицируются неявно заданные параметры, определить модули, нуждающиеся в корректировке, труднее, если только не существует документации, отражающей использование модулями общих областей. 5. Сцепление по управлению (СЦ = 7). Модуль А явно управляет функционированием модуля В с помощью передачи флагов, переключателей или кодов, посылая ему управляющие данные. Возвращение флага состояния как неявной переменной не означает сцепления по управлению. Если модуль передает информацию о самом себе или об обработанных данных, то это не всегда служит проявлением сцепления по управлению. Передача флага конца файла позволяет решить вопрос о возможности обработки этого файла. Установка флага, указывающего, какой именно способ доступа используется в операции обмена (последовательный или прямой), означает, что осуществляется сцепление по управлению, когда это влияет на модуль обмена. Если модуль имеет логическую связность и при его вызове используется переключатель, указывающий на требуемую функцию, вызываемый и вызывающий модули сцеплены по управлению. 6. Сцепление по внешним ссылкам (СЦ = 9). Модуль имеет сцепление по внешним ссылкам, если у него есть доступ к данным в другом модуле через внешнюю точку входа. Таким путем осуществляется неявное управление функционированием другого модуля. Сцепление такого типа возникает, например, при использовании некоторых языков программирования («Паскаль»), когда внутренние процедуры оперируют с глобальными переменными. 7. Сцепление по кодам (содержанию) (СЦ = 10). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом. 14. Дайте определение технологии программирования. Какие технологии Вы знаете и к каким периодам относится появление этих технологий? Технология программирования — это совокупность методов и средств для разработки программного обеспечения Какие современные технологии вы знаете: Химическая технология. Появление химической технологии относится к концу XVIII века Машиностроительные технологии. Возникновение машиностроения как отрасли промышленности относится к 18 веку Нанотехнологии нанотехнологии берут свое начало лишь в 1989 Биотехнологии. Настоящая генная инженерия, биотехнология, как современный вид науки, начала развиваться только лишь в середине прошлого столетия. 15. Дайте определение объектно-ориентированного программирования (ООП). Назовите и охарактеризуйте основные свойства ООП. 1)Объектно-ориентированное программирование (сокращенно ООП) — это парадигма разработки программных систем, в которой приложения состоят из объектов. Объекты — это сущности, у которых есть свойства и поведение. Обычно объекты являются экземплярами какого-нибудь класса. Например, в игре может быть класс Character (персонаж), а его экземплярами будут hero или npc. 2) Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений (рис. 1.6). 16. Блочно-иерархический подход к созданию программных систем. В природе существуют иерархии “целое-часть”, “простое-сложное” (иерархия развития систем в процессе эволюции). В этой иерархии любая функционирующая система является результатом развития более простой системы. Именно данный вид иерархии реализуется механизмом наследования объектно-ориентированного программирования. Будучи в значительной степени отражением природных и технических систем, программные системы обычно являются иерархическими, т.е. обладают описанными выше свойствами. На этих свойствах иерархических систем строится блочно-иерархический подход. Этот подход предполагает сначала создание частей таких объектов, а затем “сборку” из них самого объекта. 17. Проблемы разработки сложных программных систем. Большинство современных программных систем объективно очень сложны. Эта сложность обуславливается многими причинами, главной из которых является логическая сложность решаемых ими задач. Пока вычислительных установок было мало, и их возможности были ограничены, ЭВМ применяли в очень узких областях науки и техники, причем, в первую очередь, там, где решаемые задачи были хорошо детерминированы и требовали значительных вычислений. В наше время, когда созданы мощные компьютерные сети, появилась возможность переложить на них решение сложных ресурсоемких задач, о компьютеризации которых раньше никто и не думал. Сейчас в процесс компьютеризации вовлекаются совершенно новые предметные области, а для уже освоенных областей усложняются уже сложившиеся постановки задач. Дополнительными факторами, увеличивающими сложность разработки программных систем, являются: сложность формального определения требований к программным системам; отсутствие удовлетворительных средств описания поведения дискретных систем с большим числом состояний при недетерминированной последовательности входных воздействий; коллективная разработка; необходимость увеличения степени повторяемости кодов. Сложность определения требований к программным системам. Сложность определения требований к программным системам обусловливается двумя факторами. Во-первых, при определении требований необходимо учесть большое количество различных факторов. Во-вторых, разработчики программных систем не являются специалистами в автоматизируемых предметных областях, а специалисты в предметной области, как правило, не могут сформулировать проблему в нужном ракурсе. Отсутствие удовлетворительных средств формального описания поведения дискретных систем. В процессе создания программных систем используют языки сравнительно низкого уровня. Это приводит к ранней детализации операций в процессе создания программного обеспечения и увеличивает объем описаний разрабатываемых продуктов, который, как правило, превышает сотни тысяч операторов языка программирования. Средств же, позволяющих детально описывать поведение сложных дискретных систем на более высоком уровне, чем универсальный язык программирования, не существует. Коллективная разработка. Из-за больших объемов проектов разработка программного обеспечения ведется коллективом специалистов. Работая в коллективе, отдельные специалисты должны взаимодействовать друг с другом, обеспечивая целостность проекта, что при отсутствии удовлетворительных средств описания поведения сложных систем, упоминавшемся выше, достаточно сложно. Причем, чем больше коллектив разработчиков, тем сложнее организовать процесс работы. Необходимость увеличения степени повторяемости кодов. На сложность разрабатываемого программного продукта влияет и то, что для увеличения производительности труда компании стремятся к созданию библиотек компонентов, которые можно было бы использовать в дальнейших разработках. Однако в этом случае компоненты приходится делать более универсальными, что в конечном итоге увеличивает сложность разработки. Вместе взятые, эти факторы существенно увеличивают сложность процесса разработки. Однако очевидно, что все они напрямую связаны со сложностью объекта разработки - программной системы. 18. Дайте определение модели жизненного цикла (ЖЦ) программного продукта (ПП). Каскадная модель ЖЦ ПП. Область применения, достоинства и недостатки. Моделью жизненного цикла программной системы называют структуру, которая определяет последовательность осуществления действий и задач, выполненных на протяжении ЖЦ программного продукта МЖЦ определяет перечень этапов преображения, проектируемого в программное средство и программный продукт, а также, критерии перехода от этапа к этапу. Традиционная модель ЖЦ строится по каскадному принципу, суть которой состоит в том, что переход на следующий этап происходит после окончания предыдущего. Каскадные модели на протяжении всего времени их существования используются при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков. Достоинства каскадной модели ЖЦ: 1) На каждом этапе формируется законченный набор проектной документации, отвечающей критерия полноты и согласованности. 2) Выполняемые логические этапы работы позволяют планировать затраты и сроки завершения Недостатки каскадной модели ЖЦ: Существенная задержка получения результатов Ошибки и недоработки на любом из этапов выясняется на последних этапах, что приводит к необходимости возврата на предыдущие этапы. Сложность распараллеливания по проекту Сложность управления проектом Высокий уровень риска и ненадежность инвестиций. 19. Этапы жизненного цикла (ЖЦ) программных продуктов (ПП). Схема ЖЦ ПП. Анализ, посредством которого осуществляется формализация описания и предъявление к автономной системе (АС) обработки информации требований  проектирование, разработка некоторых структур разрабатываемого ПО функциональных спецификаций отдельных модулей и структур данных БД программирование - кодирование отдельных функциональных модулей тестирование и отладка в процессе которого выделяется соответствие ПП спецификациям Эксплуатация и сопровождение 20. Функциональное и структурное тестирование программ: цели, отличия стратегий, рекомендации по применению. Первый состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей, либо спецификаций сопряжения программы или модуля. Программа при этом рассматривается как черный ящик (стратегия ‘черного ящика’). Существо такого подхода - проверить соответствует ли программа внешним спецификациям. При этом логика модуля совершенно не принимается во внимание. Второй подход основан на анализе логики программы (стратегия ‘белого ящика’). Существо подхода - в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается. 21. Этапы тестирования программ. Стадии тестирования в процессе разработки программного обеспечения. Методы, используемые на каждой стадии. Этапы: а) постановка задачи для теста, б) проектирование теста, в) написание тестов, г) тестирование тестов, д) выполнение тестов, е) изучение результатов тестирования. Стадии: 1) Автономное тестирование компонентов программного обеспечения. Методы: инспекция исходного кода, сквозные просмотры, проверка за столом, оценка программ, методы покрытия операторов, покрытия решений, покрытия условий, комбинаторного покрытия, эквивалентного разбиения, анализ граничных значений, анализ причинно-следственных связей, предположение об ошибке. 2) Комплексное тестирование разрабатываемых программ. Методы: восходящее и нисходящее тестирование, комбинированный подход. 3) Системное или оценочное тестирование на соответствие основным критериям качества. Методы: тестирование удобства использования, на предельных объёмах, на предельных нагрузках, удобства эксплуатации, защиты, производительности, требований к памяти, конфигурации оборудования, совместимости, удобства установки, надёжности, восстановления, удобства обслуживания, документации, процедуры. 22. Ручной контроль как метод тестирования. Ручной контроль обычно используют на ранних этапах разработки. Различают статический и динамический подходы к ручному контролю. При статическом подходе анализируют структуру, управляющие и информационные связи программы, ее входные и выходные данные. При динамическом - выполняют ручное тестирование., т. е. вручную моделируют процесс выполнения программы на заданных исходных данных. Исходными данными для таких проверок являются: ТЗ, спецификации, структурная и функциональная схемы программного продукта, схемы отдельных компонентов ит. д., а для более поздних этапов - алгоритмы и тексты программ, а также тестовые наборы. Основные методы ручного контроля: инспекции исходного текста (чтение кода, проверка логики группой специалистов с опросом программиста), сквозные просмотры (имитация работы программы на бумаге группой специалистов, выявление ошибок в ходе тестов), проверка за столом (проверка исходного текста или сквозные просмотры, выполняемые одним человеком, не автором программы), оценки программ (анонимная оценка программы в терминах ее общего качества, простоты эксплуатации и ясности). 23. Методы структурного тестирования. Общий недостаток методов. Структурное тестирование или иначе тестирование по принципу “белого ящика” характеризуется степенью, какой тесты выполняют или покрывают логику (исходный текст) программы. Метод покрытия операторов. Цель метода - выполнение каждого оператора программы хотя бы один раз. Метод покрытия решений (покрытия переходов). Согласно данному методу должно быть написано достаточное число тестов, такое, что каждое направление перехода должно быть реализовано по крайней мере один раз. Метод покрытия условий. В этом случае записывается число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз. Критерий решений (условий). Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз, все результаты каждого решения выполнялись по крайней мере один раз и, кроме того, каждой точке входа передавалось управление по крайней мере один раз. Метод комбинаторного покрытия условий. Комбинаторное покрытие условий требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись по крайней мере один раз. Структурный подход к тестированию имеет ряд недостатков. Так тестовые наборы, построенные по данной стратегии: • не обнаруживают пропущенных маршрутов; • не обнаруживают ошибок, зависящих от обрабатываемых данных, например, в операторе if (a - b) < eps - пропуск функции абсолютного значения abs проявится только, если а < Ь; • не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию. 24. Методы функционального тестирования. Области применения. Область применения - черный ящик. Метод эквивалентного разбиения а) каждый тест должен включать столько различных входных условий, сколько это возможно, с тем чтобы минимизировать общее число тестов; б) необходимо пытаться разбить входную область программы на конечное число классов эквивалентности так, чтобы можно было предположить, что каждый тест, являющийся представителем некоторого класса, эквивалентен любому другому тесту этого класса. Другими словами, если один тест класса эквивалентности обнаруживает ошибку, то следует ожидать, что и все другие тесты этого класса эквивалентности будут обнаруживать эту ошибку. И наоборот, если тест не обнаруживает ошибки, то следует ожидать, что ни один тест этого класса эквивалентности не будет обнаруживать ошибки. Эти два положения составляют основу методологии тестирования по стратегии “черного ящика”, известного как эквивалентное разбиение/1/. Второе положение используется для разработки набора “интересных условий”, которые должны быть протестированы, а первое - для разработки минимального набора тестов, покрывающих эти условия. Разработка тестов методом эквивалентного разбиения осуществляется в два этапа: а) выделение класса эквивалентности; б) построение тестов. Метод анализа граничных значений Опыт показывает, что тесты, исследующие граничные условия, приносят большую пользу, чем тесты, которые их не исследуют. Определение: граничные условия — это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности. Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях: - выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы проверить тестом каждую границу этого класса. - при разработке тестов рассматривают не только входные условия (пространство входов), но и пространство результатов, то есть выходные классы эквивалентности. Метод анализа граничных значений требует творческого подхода и специализации. Одним из методов тестирования программ по стратегии ‘черного ящика’ является метод функциональных диаграмм. Он хорошо вписывается в методы структурного анализа, реализующиеся в современных CASE-средствах разработки программного обеспечения. Метод сводится к получению в качестве промежуточного результата таблицы решений и составления тестов по этой таблице. Тестирование ТР заключается в том, что проектируется такое количество тестов, которое позволяет покрыть все возможные комбинации условий. Как правило, количество этих тестов совпадает с числом столбцов в ТР. Метод достаточно прост, позволяет эффективно проверить соответствие разработанной программы ее внешним спецификациям, но не всегда позволяет выявить случаи, когда программа делает то, что спецификацией не предусмотрено. Кроме того, спецификация может содержать ошибки, которые при таком тестировании выявлены не будут, особенно если результаты тестирования являются правдоподобными. Предварительное построение сначала функциональных диаграмм, а затем ТР позволяет осуществлять логический контроль спецификации сначала на уровне функциональных диаграмм, а затем уже на уровне ТР, что значительно снижает вероятность ошибок в спецификации. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||