close

Вход

Забыли?

вход по аккаунту

?

ОтветыТРПО

код для вставкиСкачать
Билет 1
1. Восходящее тестирование.
2. ГОСТ 19.701-90 ЕСПД. Схемы данных.
Задача: Определить сложность следующей процедуры:*
1) Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. Такой порядок разработки программы на первый взгляд кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется наличия текстов используемых им модулей  для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). В-третьих, при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе.
При восходящем тестировании окружение содержит только один отладочный модуль, головной в тестируемой программе - ведущий (или драйвер). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и выдает необходимые сообщения. Достоинства восходящего тестирования: 1) простота подготовки тестов, 2) возможность полной реализации плана тестирования модуля. Недостатки восходящего тестирования: 1) тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя;
2) большой объем отладочного программирования;
3) необходимость специального тестирования сопряжения модулей.
2)
Билет 2
1. Нисходящее тестирование.
2. Функции представителя заказчика в выполнении программного проекта.
Задача: Определить сложность следующей процедуры:*
1) Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При этом первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом те модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми заглушками [7.5]). Каждый имитатор модуля представляется весьма простым программным фрагментом, который, в основном, сигнализирует о самом факте обращения к имитируемому модулю, производит необходимую для правильной работы программы обработку значений его входных параметров (иногда с их распечаткой) и выдает, если это необходимо, заранее запасенный подходящий результат. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется самим этим модулем и, кроме того, добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем "отладочного" программирования при восходящем тестировании заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для того, чтобы подыгрывать процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать.
При нисходящем тестировании окружение в качестве отладочных содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных модулей. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов. Достоинства нисходящего тестирования: 1) большинство тестов готовится в форме, рассчитанной на пользователя;
2) во многих случаях относительно небольшой объем отладочного программирования;
3) отпадает необходимость тестирования сопряжения модулей. Недостатком нисходящего тестирования: является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно - оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами. Билет 3
1. Пошаговое тестирование.
2. ГОСТ 19.701-90 ЕСПД. Схема работы системы.
Задача: Определить сложность следующей процедуры:*
1) Пошаговое тестирование
При пошаговом тестировании каждый модуль для своего тестирования подключается к набору уже проверенных модулей. При пошаговом тестировании модули проверяются не изолированно друг от друга, поэтому требуются либо только драйверы, либо только заглушки.
При пошаговом тестировании возможны две стратегии подключения модулей: нисходящая и восходящая.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага. Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тесты для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия. Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты. Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты. Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты. 5.3. Комплексная отладка ПС. Организация тестирования в объектно-ориентированных системах.
2) Смотри 24 билет
Билет 4
1. Монолитное тестирование.
2. Функции руководителя группы программистов в программном проекте.
Задача: Специфицировать
1) При монолитном тестировании сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования. Для автономного тестирования каждого модуля требуется модуль - драйвер и несколько модулей - заглушек (имитирующих работу модулей, вызываемых из тестируемого).
2) Билет 5
1. Проектирование теста. Классы эквивалентности.
2. Интеллектуальные возможности человека, используемые при разработке программного средства.
Задача: Построить таблицу истинности для функции согласно правилам RSL*
1) Методики проектирования тестов
Черный ящик: * Эквивалентное разбиение * Анализ граничных значений * Метод функциональных диаграмм Стеклянный ящик: * Покрытие строк * Покрытие условий * Покрытие условных операторов Эквивалентное разбиение
* Технология проектирования тестов, ориентированная на снижение общего числа тестов
* Основная мысль - разбить все данные для программы на классы
* Если проектировать тесты для каждого класса, а не для каждого члена класса - то общее число тестов уменьшится Правильный тест
* Уменьшает более чем на единицу число других тестов, которые нужно разработать для достижения приемлемого уровня тестирования
* Покрывать значительную часть других возможных тестов
Разработка тестов идет в два этапа:
* Выделение классов эквивалентности
* Построение тестов
Входные условия Правильные классы эквивалентности Неправильные классы
эквивалентности Правила выделения классов эквивалентности
* Если входное условие описывает диапазон, то выделяют один правильный класс эквивалентности и два неправильных
* Если входное условие описывает множество значений, каждое из которых трактуется особо, то определяется правильный класс эквивалентности для каждого из значений и один неправильный класс значений
* Если входное условие трактуется как "должно быть", то делается один правильный класс эквивалентности и один неправильный
* Если есть подозрение, что различные элементы класса эквивалентности могут трактоваться программой по разному, следует разбить класс на несколько подклассов
Правила составления тестов
* Каждому классу эквивалентности назначается уникальный номер
* Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности до тех пор, пока не будут покрыты все правильные классы эквивалентности
* Проектирование тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности пока все неправильные классы эквивалентности не будут покрыты тестами Пример: Программа получается на вход 3 целых значения. Эти числа являются длинами сторон треугольника. Результатом работы программы является сообщение - каким является этот треугольник: прямоугольным, равносторонним, равнобедренным, неравносторонний. "?": расписать классы эквивалентности
Решение:
Корректные классы
* (2,2,2) - равносторонний
* (3,2,2) - равнобедренный
* (3,4,5) - прямоугольный
* (2,3,4) - неравносторонний Некорректные классы
* (2,2,-1) - отрицательная сторона
* (3,2,1) - вырожденный
* (2,2,0) - нулевая длина
* (5,3,1) - не треугольник
(2,3,А) - не число
2) 2.1 Интеллектуальные возможности человека. Дейкстра [2.1] выделяет три интеллектуальные возможности человека, используемые при разработке ПС:
* способность к перебору, * способность к абстракции,
* способность к математической индукции.
Способность человека к перебору связана с возможностью последовательного переключения внимания с одного предмета на другой, позволяя узнавать искомый предмет. Эта способность весьма ограничена - в среднем человек может уверенно (не сбиваясь) перебирать в пределах 1000 предметов (элементов). Человек должен научиться действовать с учетом этой своей ограниченности. Средством преодоления этой ограниченности является его способность к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом (другого рода). Способность человека к математической индукции позволяет ему справляться с бесконечными последовательностями.
При разработке ПС человек имеет дело с системами. Под системой будем понимать совокупность взаимодействующих (находящихся в отношениях) друг с другом элементов. ПС можно рассматривать как пример системы. Логически связанный набор программ является другим примером системы. Любая отдельная программа также является системой. Понять систему  значит осмысленно перебрать все пути взаимодействия между ее элементами. В силу ограниченности человека к перебору будем различать простые и сложные системы [2.2]. Под простой будем понимать такую систему, в которой человек может уверенно перебирать все пути взаимодействия между ее элементами, а под сложной будем понимать такую систему, в которой он этого делать не в состоянии. Между простыми и сложными системами нет четкой границы, поэтому можно говорить и о промежуточном классе систем: к таким системам относятся программы, о которых программистский фольклор утверждает, что "в каждой отлаженной программе имеется хотя бы одна ошибка". При разработке ПС мы не всегда можем уверенно знать о всех связях между ее элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n! , где n  число ее элементов. Систему назовем малой, если n < 7 (6! = 720 < 1000), систему назовем большой, если n > 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования  научиться делать большие системы простыми.
Полученная оценка простых систем по числу элементов широко используется на практике. Так, для руководителя коллектива весьма желательно, чтобы в нем не было больше шести взаимодействующих между собой подчиненных. Весьма важно также следовать правилу: "все, что может быть сказано, должно быть сказано в шести пунктах или меньше". Этому правилу мы будем стараться следовать в настоящем пособии: всякие перечисления взаимосвязанных утверждений (набор рекомендаций, список требований и т.п.) будут соответствующим образом группироваться и обобщаться. Полезно ему следовать и при разработке ПС.
Билет 6
1. Основные источники ошибок в программных средствах.
2. Структурированное (структурное) программирование. Основные понятия.
Задача: Описание данных в RSL*
*) выдаётся отдельно
1) Лекция 2.2. Неправильный перевод как причина ошибок в программных средствах. При разработке и использовании ПС мы многократно имеем дело [2.3, стр. 22-28] с преобразованием (переводом) информации из одной формы в другую (см. рис.2.1). Заказчик формулирует свои потребности в ПС в виде некоторых требований. Исходя из этих требований, разработчик создает внешнее описание ПС, используя при этом спецификацию (описание) заданной аппаратуры и, возможно, спецификацию базового программного обеспечения. На основании внешнего описания и спецификации языка программирования создаются тексты программ ПС на этом языке. По внешнему описанию ПС разрабатывается также и пользовательская документация. Текст каждой программы является исходной информацией при любом ее преобразовании, в частности, при исправлении в ней ошибки. Пользователь на основании документации выполняет ряд действий для применения ПС и осуществляет интерпретацию получаемых результатов. Везде здесь, а также в ряде других процессах разработки ПС, имеет место указанный перевод информации. Рис. 2.1. Грубая схема разработки и применения ПС.
На каждом из этих этапов перевод информации может быть осуществлен неправильно, например, из-за неправильного понимания исходного представления информации. Возникнув на одном из этапов разработки ПС, ошибка в представлении информации преобразуется в новые ошибки результатов, полученных на последующих этапах разработки, и, в конечном счете, окажется в ПС.
2.3. Модель перевода.
Чтобы понять природу ошибок при переводе рассмотрим модель [2.3, стр. 22-28], изображенную на рис.2.2. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:
Рис.2.2. Модель перевода. * он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;
* он запоминает полученную информацию в своей памяти M;
* он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;
* с помощью этого механизма он фиксирует представление B.
На каждом из этих шагов человек может совершить ошибку раз-
ной природы. На первом шаге способность человека "читать между
строк" (способность, которая часто оказывается полезной, позволяя ему понимать текст, содержащий неточности или даже ошибки) может стать причиной ошибки в ПС. Ошибка возникает в том случае, когда при чтении документа A человек, пытаясь восстановить недостающую информацию, видит то, что он ожидает, а не то, что имел в виду автор документа A. В этом случае лучше было бы обратиться к автору документа за разъяснениями. При запоминании информации человек осуществляет ее осмысливание (здесь важен его уровень подготовки и знание предметной области, к которой относится документ A). И, если он поверхностно или неправильно поймет, то информация будет запомнена в искаженном виде. На третьем этапе забывчивость человека может привести к тому, что он может выбрать из своей памяти не всю преобразуемую информацию или не все правила перевода, в результате чего перевод будет осуществлен неверно. Это обычно происходит при большом объеме плохо организованной информации. И, наконец, на последнем этапе стремление человека быстрее зафиксировать информацию часто приводит к тому, что представление этой информации оказывается неточным, создавая ситуацию для последующей неоднозначной ее интерпретации. 2) Лекция 8.2. Структурное программирование.
При программировании модуля следует иметь в виду, что программа должна быть понятной не только компьютеру, но и человеку: и разработчик модуля, и лица, проверяющие модуль, и тестовики, готовящие тесты для отладки модуля, и сопроводители ПС, осуществляющие требуемые изменения модуля, вынуждены будут многократно разбирать логику работы модуля. В современных языках программирования достаточно средств, чтобы запутать эту логику сколь угодно сильно, тем самым, сделать модуль трудно понимаемым для человека и, как следствие этого, сделать его ненадежным или трудно сопровождаемым. Поэтому необходимо принимать меры для выбора подходящих языковых средств и следовать определенной дисциплине программирования. В связи с этим Дейкстра [8.2] и предложил строить программу как композицию из нескольких типов управляющих конструкций (структур), которые позволяют сильно повысить понимаемость логики работы программы. Программирование с использованием только таких конструкций назвали структурным.
Рис. 8.1. Основные управляющие конструкции структурного программирования.
Основными конструкциями структурного программирования являются: следование, разветвление и повторение (см. Рис. 8.1). Компонентами этих конструкций являются обобщенные операторы (узлы обработки [8.5]) S, S1, S2 и условие (предикат) P. В качестве обобщенного оператора может быть либо простой оператор используемого языка программирования (операторы присваивания, ввода, вывода, обращения к процедуре), либо фрагмент программы, являющийся композицией основных управляющих конструкций структурного программирования. Существенно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход.
Структурное программирование иногда называют еще "программированием без GO TO".
Из ВИКИ:
Структу́рное программи́рование - методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом.
В соответствии с данной методологией
1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
* последовательное исполнение - однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
* ветвление - однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
* цикл - многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).
В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается.
2. Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы.
3. Разработка программы ведётся пошагово, методом "сверху вниз".
Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются "заглушки", которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной "затычки", которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.
Теорема о структурном программировании:
Основная статья: Теорема Бома-Якопини
Любую схему алгоритма можно представить в виде композиции вложенных блоков begin и end, условных операторов if, then, else, циклов с предусловием (while) и может быть дополнительных логических переменных (флагов).
Эта теорема была сформулирована итальянскими математиками К. Бомом и Дж. Якопини в 1966 году и говорит нам о том, как можно избежать использования оператора перехода goto.
Билет 7
1. Основные характеристики качества программного средства.
2. Модульное программирование. Основные понятия и типовые средства.
Задача: Описание функции в RSL*
1) Лекция 4.3. Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость, защищенность.
Легкость применения: П-документированность, информативность (только применительно к документации по применению), коммуникабельность, устойчивость, защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифицируемость. Изучаемость  это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС. Модифицируемость  это характеристики ПС, которые позволяют автоматически настраивать на условия применения ПС или упрощают внесение в него вручную необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность, модульность.
Ниже даются определения используемых примитивов качества ПС [4.3-4.5].
Завершенность (completeness)  свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.
Точность (accuracy)  мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.
Автономность (self-containedness)  свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.
Устойчивость (robustness)  свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
Защищенность (defensiveness)  свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
П-документированность (u. documentation)  свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС.
Информативность (accountability)  свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования.
Коммуникабельность (communicativeness)  свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием. Временн(я эффективность (time efficiency)  мера, характеризующая способность ПС выполнять возложенные на него функции в течение определенного отрезка времени.
Эффективность по ресурсам (resource efficiency)  мера, характеризующая способность ПС выполнять возложенные на него функции при определенных ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency)  мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.
С-документировапнность (documentation)  свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данного ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.
Понятность (understandability)  свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ИСО [4.4], как согласованность, самодокументированность, четкость и, собственно, понятность (текстов программ).
Структурированность (structuredness)  свойство, характеризующее программы ПС с точки зрения организации взаимосвязанных их частей в единое целое определенным образом (например, в соответствии с принципами структурного программирования).
Удобочитаемость (readability)  свойство, характеризующее легкость восприятия текста программ ПС (отступы, фрагментация, форматированность).
Расширяемость (augmentability)  свойство, характеризующее способность ПС к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент.
Модифицируемость (modifiability)  мера, характеризующая ПС с точки зрения простоты внесения необходимых изменений и доработок на всех этапах и стадиях жизненного цикла ПС.
Модульность (modularity)  свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств (device independence)  свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях компьютеров).
2)7.1. Цель модульного программирования.
Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями [7.1, 7.2]. А сам такой метод разработки программ называют модульным программированием [7.3]. Программный модуль  это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).
Модульное программирование является воплощением в процессе разработки программ обоих общих методов борьбы со сложностью (см. лекцию 3, п. 3.5): и обеспечение независимости компонент системы, и использование иерархических структур. Для воплощения первого метода формулируются определенные требования, которым должен удовлетворять программный модуль, т.е. выявляются основные характеристики "хорошего" программного модуля. Для воплощения второго метода используют древовидные модульные структуры программ (включая деревья со сросшимися ветвями).
7.2. Основные характеристики программного модуля.
Не всякий программный модуль способствует упрощению программы [7.2]. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт [7.4] предложил следующие два общих таких критерия:
* хороший модуль снаружи проще, чем внутри;
* хороший модуль проще использовать, чем построить.
Майерс [7.5] предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики: * размер модуля, * прочность модуля, * сцепление с другими модулями, * рутинность модуля (независимость от предыстории обращений к нему).
Размер модуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и могут не окупать накладных расходов, связанных с их оформлением. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций программы при отладке программы. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность модуля  это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней
по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс [7.5] предлагает упорядоченный по степени прочности набор из семи классов модулей. Самой слабой степенью прочности обладает модуль, прочный по совпадению. Это такой модуль, между элементами которого нет осмысленных связей. Такой модуль может быть выделен, например, при обнаружении в разных местах программы повторения одной и той же последовательности операторов, которая и оформляется в отдельный модуль. Необходимость изменения этой последовательности в одном из контекстов может привести к изменению этого модуля, что может сделать его использование в других контекстах ошибочным. Такой класс программных модулей не рекомендуется для использования. Вообще говоря, предложенная Майерсом упорядоченность по степени прочности классов модулей не бесспорна. Однако, это не очень существенно, так как только два высших по прочности класса модулей рекомендуются для использования. Эти классы мы и рассмотрим подробнее.
Функционально прочный модуль  это модуль, выполняющий (реализующий) одну какую-либо определенную функцию. При реализации этой функции такой модуль может использовать и другие модули. Такой класс программных модулей рекомендуется для использования.
Информационно прочный модуль  это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Для каждой из этих операций в таком модуле имеется свой вход со своей формой обращения к нему. Такой класс следует рассматривать как класс программных модулей с высшей степенью прочности. Информационно прочный модуль может реализовывать, например, абстрактный тип данных.
В модульных языках программирования как минимум имеются средства для задания функционально прочных модулей (например, модуль типа FUNCTION в языке ФОРТРАН). Средства же для задания информационно прочных модулей в ранних языках программирования отсутствовали. Эти средства появились только в более поздних языках. Так в языке программирования Ада средством задания информационно прочного модуля является пакет [7.6].
Сцепление модуля  это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Майерс предлагает [7.5] упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо. Не рекомендуется использовать также сцепление по общей области  это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Такой вид сцепления модулей реализуется, например, при программировании на языке ФОРТРАН с использованием блоков COMMON. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу [7.5])  это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).
Рутинность модуля  это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Майерс [7.5] не рекомендует использовать зависящие от предыстории (непредсказуемые) модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация является неконструктивной, так как во многих случаях именно зависящий от предыстории модуль является лучшей реализаций информационно прочного модуля. Поэтому более приемлема следующая (более осторожная) рекомендация:
* всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;
* зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;
* в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возможно прогнозировать поведение (эффект выполнения) данного модуля при разных последующих обращениях к нему.
В связи с последней рекомендацией может быть полезным определение внешнего представления (ориентированного на информирование человека) состояний зависящего от предыстории модуля. В этом случае эффект выполнения каждой функции (операции), реализуемой этим модулем, следует описывать в терминах этого внешнего представления, что существенно упростит прогнозирование поведения данного модуля.
Билет 8
1. Понятие надёжности программного средства.
2. Язык RSL. Основные понятия и области применения.
Задача: Оценить сложность
1) 1.3. Надежность программного средства.
Альтернативой правильного ПС является надежное ПС. Надежность (reliability) ПС  это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью [1.5]. При этом под отказом в ПС понимают проявление в нем ошибки [1.2, стр. 10-13]. Таким образом, надежное ПС не исключает наличия в нем ошибок  важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПС. ПС может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно характеризовать [1.2, стр. 10-13] вероятностью работы ПС без отказа в течение определенного периода времени. Однако в силу специфических особенностей ПС определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике. Позже мы вернемся к более обстоятельному обсуждению этого вопроса.
При оценке степени надежности ПС следует также учитывать последствия каждого отказа. Некоторые ошибки в ПС могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности ПС иногда используют дополнительные показатели, учитывающие стоимость (вред) для пользователя каждого отказа.
Рассмотрим теперь общие принципы обеспечения надежности ПС, что, как мы уже подчеркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надежности:
- предупреждение ошибок;
- самообнаружение ошибок;
- самоисправление ошибок;
- обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах, в нашем случае - в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
- борьба со сложностью,
- обеспечение точности перевода,
- преодоление барьера между пользователем и разработчиком,
- обеспечение контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т.е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надежности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах.Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во - первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во - вторых, добавление в программу дополнительных фрагментов приводит к ее усложнению (иногда - значительному), что в какой то мере мешает методам предупреждения ошибок.
Билет 9
1. Понятие масштабируемости программного средства.
2. Метрики сложности программ .
Задача: Специфицировать программу ...*
1) Масштабируемость программного обеспечения - способность программного обеспечения корректно работать на малых и на больших системах с производительностью, которая увеличивается пропорционально вычислительной мощности системы.
Билет 10
1. Специфические особенности программного средства как изделия.
2. Защищённость программного средства и способы её обеспечения.
Задача: Составить тесты для программы, вычисляющей ...*
1) Разработка программных средств имеет ряд специфических особенностей [3.1].
Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки - программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а переход от неформального к формальному существенно неформален.
Разработка ПС носит творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца.
Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т.е. статических объектов), смысл же (семантика) этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т.е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств.
Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.
2) Различают следующие виды защиты ПС от искажения информации:
защита от сбоев аппаратуры;
защита от влияния "чужой" программы;
защита от отказов "своей" программы;
защита от ошибок оператора (пользователя);
защита от несанкционированного доступа;
защита от защиты.
Защита от сбоев аппаратуры в настоящее время является не очень злободневной задачей (с учетом уровня достигнутой надежности компьютеров). Но все же полезно знать ее решение. Это обеспечивается организацией так называемых "двойных-тройных просчетов". Для этого весь процесс обработки данных, определяемый ПС, разбивается по времени на интервалы так называемыми "опорными точками". Длина этого интервала не должна превосходить половины среднего времени безотказной работы компьютера. Копия состояния изменяемой в этом процессе памяти каждой опорной точке записывается во вторичную память с некоторой контрольной суммой (числом, вычисляемым как некоторая функция от этого состояния) в том случае, когда будет считаться, что обработка данных от предыдущей опорной точки до данной (т.е. один "просчет") произведена правильно (без сбоев компьютера). Для того, чтобы это выяснить, производится два таких "просчета". После первого "просчета" вычисляется и запоминается указанная контрольная сумма, а затем восстанавливается состояние памяти для предыдущей опорной точки и делается второй "просчет". После второго "просчета" вычисляется снова указанная контрольная сумма, которая затем сравнивается с контрольной суммой первого "просчета". Если эти две контрольные суммы совпадают, второй просчет считается правильным, в противном случае контрольная сумма второго "просчета" также запоминается и производится третий "просчет" (с предварительным восстановлением состояния памяти для предыдущей опорной точки). Если контрольная сумма третьего "просчета" совпадет с контрольной суммой одного из первых двух "просчетов", то третий просчет считается правильным, в противном случае требуется инженерная проверка компьютера.
Защита от влияния "чужой" программы относится прежде всего к операционным системам или к программам, выполняющим частично их функции. Различают две разновидности этой защиты:
защита от отказов,
защита от злонамеренного влияния "чужой" программы.
При появлении мультипрограммного режима работы компьютера в его памяти может одновременно находится в стадии выполнения несколько программ, попеременно получающих управление в результате возникающих прерываний (так называемое квазипараллельное выполнение программ). Одна из таких программ (обычно: операционная система) занимается обработкой прерываний и управлением мультипрограммным режимом. В каждой из таких программ могут возникать отказы (проявляться ошибки), которые могут повлиять на выполнение функций другими программами. Поэтому управляющая программа (операционная система) должна обеспечить защиту себя и других программ от такого влияния. Для этого аппаратура компьютера должна реализовывать следующие возможности:
защиту памяти,
два режима функционирования компьютера: привилегированный и рабочий (пользовательский),
два вида операций: привилегированные и ординарные,
корректную реализацию прерываний и начального включения компьютера,
временное прерывание.
Защита памяти означает возможность программным путем задавать для каждой программы недоступные для нее участки памяти. В привилегированном режиме могут выполняться любые операции (как ординарные, так и привилегированные), а в рабочем режиме - только ординарные. Попытка выполнить привилегированную операцию, а также обратиться к защищенной памяти в рабочем режиме вызывает соответствующее прерывание. Причем к привилегированным операциям относятся операции изменения защиты памяти и режима функционирования, а также доступа к внешней информационной среде. Начальное включение компьютера и любое прерывание должно автоматически включать привилегированный режим и отмену защиты памяти. В этом случае управляющая программа (операционная система) может полностью защитить себя от влияния других программ, если все точки передачи управления при начальном включении и прерываниях будут принадлежать этой программе, если она никакой другой программе не позволит работать в привилегированном режиме (при передаче управления любой другой программе будет включаться только рабочий режим) и если она полностью защитит свою память (содержащую, в частности, всю ее управляющую информацию, включая так называемые вектора прерываний) от других программ. Тогда никто не помешает ей выполнять любые реализованные в ней функции защиты других программ (в том числе и доступа к внешней информационной среде). Для облегчения решения этой задачи часть такой программы помещается в постоянную память, т.е. неотделима от самого компьютера. Наличие временного прерывания позволяет управляющей программе защититься от зацикливания в других программах (без такого прерывания она могла бы просто лишиться возможности управлять).
Защита от отказов "своей" программы обеспечивается надежностью этой программы, на что ориентирована вся технология программирования, обсуждаемая в настоящем курсе лекций.
Защита от ошибок пользователя (помимо ошибок входных данных, см. обеспечение устойчивости ПС) обеспечивается выдачей предупредительных сообщений о попытках изменить состояние внешней информационной среды с требованием подтверждения этих действий, а также возможностью восстановления состояния отдельных компонент внешней информационной среды. Последнее базируется на осуществлении архивирования изменений состояния внешней информационной среды.
Защита от несанкционированного доступа обеспечивается использованием секретных слов (паролей). В этом случае каждому пользователю предоставляются определенные информационные и процедурные ресурсы (услуги), для использования которых требуется предъявления ПС некоторого пароля, ранее зарегистрированного в ПС этим пользователем. Другими словами, пользователь как бы "вешает замок" на выделенные ему ресурсы, "ключ" от которого имеется только у этого пользователя. Однако, в отдельных случаях могут быть предприняты настойчивые попытки взломать такую защиту, если защищаемые ресурсы представляют для кого-то чрезвычайную ценность. Для такого случая приходится предпринимать дополнительные меры для защиты от взлома защиты.
Защита от взлома защиты связана с использованием в ПС специальных программистских приемов, затрудняющих преодоление защиты от несанкционированного доступа. Использование обычных паролей оказывается недостаточной, когда речь идет о чрезвычайно настойчивом стремлении (например, преступного характера) добиться доступа к ценной информации. Во-первых, потому, что информацию о паролях, которую использует ПС для защиты от несанкционированного доступа, "взломщик" этой защиты относительно легко может достать, если он имеет доступ к самому этому ПС. Во-вторых, используя компьютер, можно осуществлять достаточно большой перебор возможных паролей с целью найти подходящий для доступа к интересующей информации. Защититься от такого взлома можно следующим образом. Секретное слово (пароль) или просто секретное целое число X знает только владелец защищаемой информации, а для проверки прав доступа в компьютере хранится другое число Y=F(X), однозначно вычисляемое ПС при каждой попытке доступа к этой информации при предъявлении секретного слова. При этом функция F может быть хорошо известной всем пользователям ПС, однако она обладает таким свойством, что восстановление слова X по Y практически невозможно: при достаточно большой длине слова X (например, в несколько сотен знаков) для этого требуется астрономическое время. Такое число Y будем называть электронной (компьютерной) подписью владельца секретного слова X (а значит, и защищаемой информации).
Другая разновидность такой защиты связана с защитой сообщений, пересылаемых по компьютерным сетям, преднамеренных (или злонамеренных) искажений. Такое сообщения может перехватываться на "перевалочных" пунктах компьютерной сети и подменяться другим сообщением от автора перехваченного сообщения. Такая ситуация возникает прежде всего при осуществлении банковских операций с использованием компьютерной сети. Путем подмены такого сообщения, являющего распоряжением владельца банковского счета о выполнении некоторой банковской операции деньги с его счета могут быть переведены на счет "взломщика" защиты (своеобразный вид компьютерного ограбления банка). Защиту от такого взлома защиты можно осуществить следующим образом [11.4]. Наряду с функцией F, определяющей компьютерную подпись владельца секретного слова X, которую знает адресат защищаемого сообщения (если только ее владелец является клиентом этого адресата), в ПС определена другая функция Stamp, по которой отправитель сообщения должен вычислить число S=Stamp(X,R), используя секретное слово X и текст передаваемого сообщения R. Функция Stamp также считается хорошо известной всем пользователям ПС и обладает таким свойством, что по S практически невозможно ни восстановить число X, ни подобрать другое сообщение R с соответствующей компьютерной подписью. Само передаваемое сообщение (вместе со своей защитой) должно иметь вид:
R Y S ,
причем Y (компьютерная подпись) позволяет адресату установить истинность клиента, а S как бы скрепляет защищаемое сообщение Rс компьютерной подписью Y. В связи с этим будем называть число S электронной (компьютерной) печатью. В ПС определена еще одна функция Notary, по которой получатель защищаемого сообщения проверяет истинность передаваемого сообщения:
Notary(R,Y,S).
Эта позволяет однозначно установить, что сообщение R принадлежит владельцу секретного слова X.
Защита от защиты необходима в том случае, когда пользователь забыл (или потерял) свой пароль. Для такого случая должна быть предусмотрена возможность для особого пользователя (администратора ПС), отвечающего за функционирования системы защиты, производить временное снятие защиты от несанкционированного доступа для хозяина забытого пароля с целью дать ему возможность зафиксировать новый пароль.
Билет 11
1. Понятие открытости программного средства.
2. Устойчивость программного средства и способы её обеспечения.
Задача: Составить тесты для программы, вычисляющей ....*
1) Открытое программное обеспечение (англ. open-source software) - программное обеспечение с открытым исходным кодом. Исходный код таких программ доступен для просмотра, изучения и изменения, что позволяет пользователю принять участие в доработке самой открытой программы, использовать код для создания новых программ и исправления в них ошибок - через заимствование исходного кода, если это позволяет совместимость лицензий, или через изучение использованных алгоритмов, структур данных, технологий, методик и интерфейсов (поскольку исходный код может существенно дополнять документацию, а при отсутствии таковой сам служит документацией).
2) Этот примитив качества обеспечивается с помощью так называемого защитного программирования. Вообще говоря, защитное программирование применяется для повышения надежности ПС при программировании модуля в более широком смысле. Как утверждает Майерс [11.3], "защитное программирование основано на важной предпосылке: худшее, что может сделать модуль, - это принять неправильные входные данные и затем вернуть неверный, но правдоподобный результат". Для того, чтобы этого избежать, в текст модуля включают проверки его входных и выходных данных на их корректность в соответствии со спецификацией этого модуля, в частности, должны быть проверены выполнение ограничений на входные и выходные данные и соотношений между ними, указанные в спецификации модуля. В случае отрицательного результата проверки возбуждается соответствующая исключительная ситуация. В связи с этим в конец этого модуля включаются фрагменты второго рода - обработчики соответствующих исключительных ситуаций, которые помимо выдачи необходимой диагностической информации, могут принять меры либо по исключению ошибки в данных (например, потребовать их повторного ввода), либо по ослаблению влияния ошибки (например, мягкую остановку управляемых ПС устройств во избежание их поломки при аварийном прекращении выполнения программы). Применение защитного программирования модулей приводит снижению эффективности ПС как по времени, так и по памяти. Поэтому необходимо разумно регулировать степень применения защитного программирования в зависимости от требований к надежности и эффективности ПС, сформулированным в спецификации качества разрабатываемого ПС. Входные данные разрабатываемого модуля могут поступать как непосредственно от пользователя, так и от других модулей. Наиболее употребительным случаем применения защитного программирования является применение его для первой группы данных, что и означает реализацию устойчивости ПС. Это нужно делать всегда, когда в спецификации качества ПС имеется требование об обеспечении устойчивости ПС. Применение защитного программирования для второй группы входных данных означает попытку обнаружить ошибку в других модулях во время выполнения разрабатываемого модуля, а для выходных данных разрабатываемого модуля - попытку обнаружить ошибку в самом этом модуле во время его выполнения. По-существу, это означает частичное воплощение подхода самообнаружения ошибок для обеспечения надежности ПС, о чем шла речь в лекции 3. Этот случай защитного программирования применяется крайне редко - только в том случае, когда требования к надежности ПС чрезвычайно высоки.
Билет 12
1. Агентно-ориентированный подход к созданию программных систем.
2. ГОСТ 19.102-77: Стадии разработки программ и программной документации.
Задача: Определить сложность следующей процедуры:*
1)
2)Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. № 1268 срок действия установлен
с 01.07.1978 г. до 01.07.1983 г.
1. Настоящий стандарт устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
2. Стадии разработки, этапы и содержание работ должны соответствовать указанным в таблице.
Стадии разработкиЭтапы работСодержание работ1. Техническое заданиеОбоснование необходимости разработки программыПостановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев эффективности и качества разрабатываемой программы.
Обоснование необходимости проведения научно-исследовательских работНаучно-исследовательские работыОпределение структуры входных и выходных данных.
Предварительный выбор методов решения задач.
Обоснование целесообразности применения ранее разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения поставленной задачи1. Техническое заданиеРазработка и утверждение технического заданияОпределение требований к программе.
Разработка технико-экономического обоснования разработки программы.
Определение стадий, этапов и сроков разработки программы и документации на нее.
Выбор языков программирования.
Определение необходимости проведения научно-исследовательских работ на последующих стадиях.
Согласование и утверждение технического задания.2. Эскизный проектРазработка эскизного проектаПредварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма решения задачи.
Разработка технико-экономического обоснованияУтверждение эскизного проектаРазработка пояснительной записки.
Согласование и утверждение эскизного проекта3. Технический проектРазработка технического проектаУточнение структуры входных и выходных данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и выходных данных.
Определение семантики и синтаксиса языка.
Разработка структуры программы.
Окончательное определение конфигурации технических средствУтверждение технического проектаРазработка плана мероприятий по разработке и внедрению программ.
Разработка пояснительной записки.
Согласование и утверждение технического проекта4. Рабочий проектРазработка программыПрограммирование и отладка программы.
Изготовление программы-оригиналаРазработка программной документацииРазработка программных документов в соответствии с требованиями ГОСТ 19.101-77Испытания программыРазработка, согласование и утверждение порядка и методики испытаний.4. Рабочий проектИспытания программыПроведение предварительных, государственных, межведомственных, приемо-сдаточных и других видов испытаний.
Корректировка программы и программной документации по результатам испытаний5. ВнедрениеПодготовка и передача программыПодготовка и передача программы и программной документации для сопровождения и (или) изготовления.
Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов и программПримечания:
1. Допускается исключать вторую стадию разработки, а в технико-экономически обоснованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.
Билет 13
1. Основные задачи сопровождения программного средства.
2. Обеспечение переносимости программного средства.
Задача: Определить сложность следующей процедуры:*
1) Сопровождение (maintenance) ПС  это процесс сбора информации о качестве ПС в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях [3.1, 3.4, 3.5].
2) способность программного обеспечения работать на различных аппаратных платформах или под управлением различных операционных систем.
Билет 14
1. Стандарт FIPA взаимодействия программных (физических) агентов (physical agents).
2. ГОСТ 19_402-78: Описание программы.
Задача: Определить сложность следующей процедуры:*
1)
2) Смотри 24 билет
Билет 15
1. Типы данных, используемые в языке RSL.
2. Метод восходящей разработки структуры программы.
3. Задача: Специфицировать программу*
1)
2) Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. Такой порядок разработки программы на первый взгляд кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется наличия текстов используемых им модулей  для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). В-третьих, при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе.
Билет 16
1. Сервисы белых и жёлтых страниц в стандарте агентных систем FIPA.
2. ГОСТ 19.503-79 Единая система программной документации. Руководство системного программиста. Требования к содержанию и оформлению.
Задача: Проверить корректность спецификации программы...*
1) 2) 1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является обязательным.
1.2. Руководство системного программиста должно содержать следующие разделы:
* общие сведения о программе;
* структура программы;
* настройка программы;
* проверка программы;
* дополнительные возможности;
* сообщения системному программисту.
В зависимости от особенностей документы допускается объединять отдельные разделы или вводить новые.
В обоснованных случаях допускается раздел "Дополнительные возможности" не приводить, а в наименованиях разделов опускать слово "программа" или заменять его на "наименование программы".
(Измененная редакция, Изм. № 1).
2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе "Общие сведения о программе" должна быть указаны назначение и функции программы и сведения о технических и программных средствах, обеспечивающих выполнение данной программы.
2.2. В разделе "Структура программы" должны быть приведены сведения о структуре программы, ее составных частях, о связях между составными частями и о связях с другими программами.
2.3. В разделе "Настройка программы" должно быть приведено описание действий по настройке программы на условия конкретного применения (настройка на состав технических средств, выбор функций и др.).
При необходимости приводят поясняющие примеры.
2.4. В разделе "Проверка программы" должны быть приведено описание способов проверки, позволяющих дать общее заключение о работоспособности программы (контрольные примеры, методы прогона, результаты).
2.5. В разделе "Дополнительные возможности" должно быть приведено описание дополнительных разделов функциональных возможностей программы и способов их выбора.
2.6. В разделе "Сообщения системному программисту" должны быть указаны тексты сообщений, выдаваемых в ходе выполнения настройки, проверки программы, а также в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
2.7. В приложении к руководству системного программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.).
v
Билет 17
1. Списки и декартовы произведения в языке RSL.
2. Коструктивный подход к разработке структуры программы.
Задача: Специфицировать программу ....*
1)
2) Конструктивный подход к разработке программы представляет собой модификацию нисходящей разработки, при которой модульная древовидная структура программы формируется в процессе программирования модулей. Разработка программы при конструктивном подходе начинается с программирования головного модуля, исходя из спецификации программы в целом. При этом спецификация программы принимается в качестве спецификации ее головного модуля, который полностью берет на себя ответственность за выполнение функций программы. В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются подзадачи (внутренние функции), в терминах которых программируется головной модуль. Это означает, что для каждой выделяемой подзадачи (функции) создается спецификация реализующего ее фрагмента программы, который в дальнейшем может быть представлен некоторым поддеревом модулей. Важно заметить, что здесь также ответственность за выполнение выделенной функции несет головной (может быть, и единственный) модуль этого поддерева, так что спецификация выделенной функции является одновременно и спецификацией головного модуля этого поддерева. В головном модуле программы для обращения к выделенной функции строится обращение к головному модулю указанного поддерева в соответствии с созданной его спецификацией. Таким образом, на первом шаге разработки программы (при программировании ее головного модуля) формируется верхняя начальная часть дерева, например, такая, которая показана на рис. 7.1. Рис. 7.2. Второй шаг формирования модульной структуры программы при конструктивном подходе.
Аналогичные действия производятся при программировании любого другого модуля, который выбирается из текущего состояния дерева программы из числа специфицированных, но пока еще не запрограммированных модулей. В результате этого производится очередное доформирование дерева программы, например, такое, которое показано на рис. 7.2.
Билет 18
1. Методы сбора информации о рисках программного проекта.
2. Архитектурный подход к разработке структуры программы.
Задача: Описать функцию на языке RSL*
1) 71 стр. sw_project_...pdf
Для сбора информации о рисках могут применяться различные подходы. Среди этих подходов наиболее распространены: * Опрос экспертов * Мозговой штурм * Метод Дельфи * Карточки Кроуфорда Цель опроса экспертов - идентифицировать и оценить риски путем интервью подходящих квалифицированных специалистов. Специалисты высказывают своѐ мнение о рисках и дают им оценку, исходя из своих знаний, опыта и имеющейся информации. Этот метод может помочь избежать повторного наступления на одни и те же грабли. Перед опросом эксперт должен получить всю необходимую вводную информацию. Деятельность экспертов необходимо направлять, задавая вопросы. Во время опроса вся информация, выдаваемая экспертом, должна записываться и сохраняться. При работе с несколькими экспертами выходная информация обобщается и доводится до сведения всех задействованных экспертов. К участию в мозговом штурме привлекаются квалифицированные специалисты, которым дают "домашнее задание" - подготовить свои суждения по определенной категории рисков. Затем проводится общее собрание, на котором специалисты по очереди высказывают свои мнения о рисках. Важно: споры и замечания не допускаются. Все риски записываются, группируются по типам и характеристикам, каждому риску дается определение. Цель - составить первичный перечень возможных рисков для последующего отбора и анализа. Метод Дельфи во многом похож на метод мозгового штурма. Однако есть важные отличия. Во-первых, при применении этого метода эксперты участвуют в опросе анонимно. Поэтому результат характеризуется меньшей субъективностью, меньшей предвзятостью и меньшим влиянием отдельных экспертов. Во-вторых, опрос экспертов проводится в несколько этапов. На каждом этапе модератор рассылает анкеты, собирает и обрабатывает ответы. Результаты опроса рассылаются экспертам снова для уточнения их мнений и оценок. Такой подход позволяет достичь некоего общего мнения специалистов о рисках. Для быстрого выявления рисков можно воспользоваться еще одной из методик социометрии является известной как "Карточки Кроуфорда" [5] . Суть этой методики в следующем. Собирается группа экспертов 7-10 человек. Каждому участнику мини-исследования раздается по десять карточек (для этого вполне подойдет обычная бумага для записок). Ведущий задает вопрос: "Какой риск является наиболее важным в этом проекте?" Все респонденты должны записать наиболее, по их мнению, важный риск в данном проекте. При этом никакого обмена мнениями не должно быть. Ведущий делает небольшую паузу, после чего вопрос повторяется. Участник не может повторять в ответе один и тот же риск. После того как вопрос прозвучит десять раз, в распоряжении ведущего появятся от 70 до 100 карточек с ответами. Если группа подобрана хорошо (в том смысле, что в нее входят люди с различными точками зрения), вероятность того, что участники эксперимента укажут большинство значимых для проекта рисков, весьма высока. Остается составить список названных рисков и раздать его участникам для внесения изменений и дополнений. В качестве источника информации при выявлении рисков могут служить различные доступные контрольные списки рисков проектов разработки ПО, 73 которые следует проанализировать на применимость к данному конкретному проекту. Например, Барии Боэм [6] приводит список 10 наиболее распространенных рисков программного проекта: 1. Дефицит специалистов. 2. Нереалистичные сроки и бюджет. 3. Реализация несоответствующей функциональности. 4. Разработка неправильного пользовательского интерфейса. 5. ―Золотая сервировка‖, перфекционизм, ненужная оптимизация и оттачивание деталей. 6. Непрекращающийся поток изменений. 7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. 8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. 9. Недостаточная производительность получаемой системы. 10. ―Разрыв‖ в квалификации специалистов разных областей знаний. Демарко и Листер [1] приводят свой список из пяти наиболее важных источников рисков любого проекта разработки ПО: 1. Изъяны календарного планирования 2. Текучесть кадров 3. Раздувание требований 4. Нарушение спецификаций 5. Низкая производительность Не существует исчерпывающих контрольных списков рисков программного проекта, поэтому необходимо внимательно анализировать особенности каждого конкретного проекта. Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик: причины, условия, последствий и ущерба. Если вернуться к примеру проекта создания "Автоматизированной системы продажи документации", который мы рассматривали в предыдущих лекциях, то список главных выявленных рисков может выглядеть следующим образом:
2) Лекция 7.3 Архитектурный подход к разработке программы представляет собой модификацию восходящей разработки, при которой модульная структура программы формируется в процессе программирования модуля. Но при этом ставится существенно другая цель разработки: повышение уровня используемого языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, каждая из которых может использоваться при решении разных задач в этой области, и специфицируются, а затем и программируются отдельные программные модули, выполняющие эти функции. Так как процесс выделения таких функций связан с накоплением и обобщением опыта решения задач в заданной предметной области, то обычно сначала выделяются и реализуются отдельными модулями более простые функции, а затем постепенно появляются модули, использующие ранее выделенные функции. Такой набор модулей создается в расчете на то, что при разработке той или иной программы заданной предметной области в рамках конструктивного подхода могут оказаться приемлемыми некоторые из этих модулей. Это позволяет существенно сократить трудозатраты на разработку конкретной программы путем подключения к ней заранее заготовленных и проверенных на практике модульных структур нижнего уровня. Так как такие структуры могут многократно использоваться в разных конкретных программах, то архитектурный подход может рассматриваться как путь борьбы с дублированием в программировании. В связи с этим программные модули, создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы усилить применимость таких модулей путем настройки их на параметры.
Билет 19
1. Главные причины возможного провала программного проекта.
2. Сопровождаемость как характеристика качества программного продукта и способы её обеспечения.
Задача: Специфицировать программу ....*
1) [sw_project_management.pdf 82 страница]
Главные риски программных проектов и способы реагирования Мой список из пяти главных причин провала программных проектов - следующий:  Требования заказчика отсутствуют / не полны / подвержены частым изменениям.  Отсутствие необходимых ресурсов и опыта.  Отсутствие рабочего взаимодействия с заказчиком.  Неполнота планирования. "Забытые работы".  Ошибки в оценках трудоемкостей и сроков работ. Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели и требования. Цитата из жизни: "Была бы разработана хорошая программа, а какой процесс автоматизировать с ее помощью, мы найдем". К этому можно добавить только одно: "Когда человек не знает, к какой пристани он держит путь, для него никакой ветер не будет попутным" (Сенека Луций Аней, философ, 65-3 до н.э.) К часто упускаемым требованиям можно отнести:  Функциональные o Программы установки, настройки, конфигурации. o Миграция данных. o Интерфейсы с внешними системами. o Справочная система.  Общесистемные o Производительность. o Надежность. o Открытость. o Масштабируемость. o Безопасность. o Кросплатформенность. o Эргономичность. Как правило, эти требования "всплывают" при подготовке и проведении приемо-сдаточных испытаний и могут сильно задержать проект по времени и увеличить трудозатраты на его реализацию. Чтобы этого не происходило, следует достигать соглашения с заказчиком по всем перечисленным пунктам предпочтительнее еще на стадии инициации проекта. Например, если требования портируемости продукта на разные аппаратно-программные платформы нет, то это целесообразно включить в раздел концепции с допущениями проекта.
2) Лекция 4.3.
Сопровождаемость. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифицируемость. Изучаемость  это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС. Модифицируемость  это характеристики ПС, которые позволяют автоматически настраивать на условия применения ПС или упрощают внесение в него вручную необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.
12.4. Обеспечение сопровождаемости программного средства.
Обеспечение сопровождаемости ПС сводится к обеспечению изучаемости ПС и к обеспечению его модифицируемости. Изучаемость (подкритерий качества) ПС определяется составом и качеством документации по сопровождению ПС и выражается через такие примитивы качества ПС как С-документированность, информативность, понятность, структурированность и удобочитаемость. Последние два примитива качества и, в значительной степени, понятность связаны с текстами программных модулей. Вопрос о документации по сопровождению будет обсуждаться в следующей лекции. Здесь мы лишь сделаем некоторые общие рекомендации относительно текстов программ (модулей). При окончательном оформлении текста программного модуля целесообразно придерживаться следующих рекомендаций, определяющих практически оправданный стиль программирования [12.3, 12.4]: * используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по-возможности, включайте комментарии (хотя бы в краткой форме) на самой ранней стадии разработки текста модуля;
* используйте осмысленные (мнемонические) и устойчиво различимые имена (оптимальная длина имени  4-12 литер, цифры  в конце), не используйте сходные имена и ключевые слова;
* соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля: при ее объявлении или, в крайнем случае, при инициализации переменной в качестве константы);
* не бойтесь использовать необязательные скобки  они обходятся дешевле, чем ошибки;
* размещайте не больше одного оператора в строке; для прояснения структуры модуля используйте дополнительные пробелы (отступы) в начале каждой строки; этим обеспечивается удобочитаемость текста модуля;
* избегайте трюков, т.е. таких приемов программирования, когда создаются фрагменты модуля, основной эффект которых не очевиден или скрыт (завуалирован), например, побочные эффекты функций.
Структурированность текста модуля существенно упрощает его понимание. Обеспечение этого примитива качества подробно обсуждалось в лекции 8. Удобочитаемость текста модуля может быть обеспечена автоматически путем применения специального программного инструмента  форматера.
Модифицируемость (подкритерий качества) ПС определяется, частично, некоторыми свойствами документации, и свойствами, реализуемые программным путем, и выражается через такие примитивы качества ПС как расширяемость, модифицируемость, структурированность и модульность.
Расширяемость обеспечивается возможностями автоматически настраиваться на условия применения ПС по информации, задаваемой пользователем. К таким условиям относятся, прежде всего, конфигурация компьютера, на котором будет применяться ПС (в частности, объем и структура его памяти), а также требования конкретного пользователя к функциональным возможностям ПС (например, требования, которые определяют режим применения ПС или конкретизируют структуру информационной среды). К этим возможностям можно отнести и возможность добавления к ПС определенных компонент. Для реализации таких возможностей в ПС часто включается дополнительная компонента (подсистема), называемая инсталятором. Инсталятор осуществляет прием от пользователя необходимой информации и настройку ПС по этой информации. Обычно решение о включении в ПС такой компоненты принимается в процессе разработки архитектуры ПС.
Модифицируемость (примитив качества) обеспечивается такими свойствами документации и свойствами, реализуемые программным путем, которые облегчают внесение изменений и доработок в документацию и программы ПС ручным путем (возможно, с определенной компьютерной поддержкой). В спецификации качества могут быть указаны некоторые приоритетные направления и особенности развития ПС. Эти указания должны быть учтены при разработке архитектуры ПС и модульной структуры его программ. Общая проблема сопровождения ПС  обеспечить, чтобы все его компоненты (на всех уровнях представления) оставались согласованными в каждой новой версии ПС. Этот процесс обычно называют управлением конфигурацией (configuration management).Чтобы помочь управлению конфигурацией, необходимо, чтобы связи и зависимости между документами и их частями фиксировать в специальной документации по сопровождению [12.5]. Эта проблема усложняется, если в процессе доработки может находиться сразу несколько версий ПС (в разной степени завершенности). Тогда без компьютерной поддержки довольно трудно обеспечить согласованность документов в разных конфигурациях. Поэтому в таких случаях в ПС включается дополнительная компонента (подсистема), называемая конфигуратором. С такой компонентой связывают специальную базу данных (или специальный раздел в базе данных), в которой фиксируются связи и зависимости между документами и их частями для всех версий ПС. Обычно решение о включении в ПС такой компоненты принимается в процессе разработки архитектуры ПС. Для обеспечения этого примитива качества в документацию по сопровождению включают специальное руководство, которое описывает, какие части ПС являются аппаратно- и программно-зависимыми, и как возможное развитие ПС учтено в его строении (конструкции).
Структурированность и модульность упрощают ручную модификацию программ ПС.
Билет 20
1. Основные способы смягчения последствий реализованных рисков программного проекта.
2. ГОСТ 19 504-79 Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению.
Задача: Специфицировать программу ....*
1)
2) 1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является обязательным.
1.2. Руководство программиста должно содержать следующие разделы:
* назначение и условия применения программ;
* характеристика программы;
* обращение к программе;
* входные и выходные данные;
* сообщения.
В зависимости от особенностей документы допускается объединять отдельные разделы или вводить новые.
2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе "Назначение и условия применения программ" должны быть указаны назначение и функции, выполняемые программой, условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программного обеспечению и т.п.).
2.2. В разделе "Характеристика программы" должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т.п.).
2.3. В разделе "Обращение к программе" должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.).
2.4. В разделе "Входные и выходные данные" должно быть приведено описание организации используемой входной и выходной информации и, при необходимости, ее кодирования.
2.5. В разделе "Сообщения" должны быть указаны тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
2.6. В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.).
Билет 21
1. Тестирование программы путём покрытия её логики.
2. Показатели эффективности программного средства
Задача: Составить тесты для программы, находящей ....*
1) "Белый ящик" - тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.
Техника тестирования по принципу Белого ящика, также называемая техникой тестирования, управляемой логикой программы, позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.
Техника Белого ящика включает в себя следующие методы тестирования:
1. покрытие операторов
2. покрытие решений
3. покрытие условий
4. покрытие решений и условий
5. комбинаторное покрытие условий
Покрытие операторов
Критерии покрытия операторов подразумевает выполнение каждого оператора программы по крайней мере один раз.
Рассмотрим пример:
void func(int a, int b, float x) {
if ((a > 1) && (b == 0)) x = x/a; // пути с (истина) и b (ложь)
if (a == 2 || x > 1) x++; // пути e (истина) и d (ложь)
}
Чтобы выполнить каждый оператор не менее одного раза, нужно составить единственный тест со следующими значениями входных данных (a = 2 b = 0 x = 3).
Данный подход обладает недостатками. Вот, например, если в условии x > 1 программист допускает ошибку и пишет x < 1 или x > - 1, то с помощью нашего теста эта ошибка не будет обнаружена.
Покрытие решений
В соответствии с этим критерием необходимо составить такое число тестов, при которых каждое условие в программе примет как истинное значение, так и ложное значение.
Покрытие условий
Данный критерий является более эффективным по сравнению с предыдущими.
Записывается число тестов , достаточное для того, чтобы все возможные результаты каждого условия в решении были выполнены по крайней мере один раз.
Однако этот критерий не всегда приводит к выполнению каждого оператора по крайней мере один раз. Поэтому к этому критерию добавляется дополнительное условие, каждый оператор должен быть выполнен хотя бы один раз.
1. a = 2 ; b = 0 ; x = 4 a--c--e
2. a = 1 ; b = 1 ; x = 1 a--b--d
Если после составления тестов у нас останутся не покрытые операторы, то мы должны дополнить свой набор тестов таким образом чтобы каждый оператор выполняется не менее одного раза.
Покрытие условий и решений
В соответствии с этим критерием необходимо составить тесты так, чтобы результаты каждого условия выполнялись хотя бы один раз, результаты каждого решения так же выполнялись хотя бы один раз, и каждый оператор должен быть выполнен хотя бы один раз.
Хотя метод и является достаточно мощным и позволяет находить достаточно большое количество ошибок, он имеет и недостатки:
1. не всегда можно проверить все условия
2. невозможно проверить условия, которые скрыты другими условиям
3. метод обладает недостаточной чувствительностью к ошибкам в логических выражениях
Комбинаторное покрытие условий[
Этот критерий требует, чтобы все возможные комбинации результатов условий в каждом решении, а также каждый оператор выполнился по крайней мере один раз. В нашем примере должны быть покрыты восемь комбинаций:
1. а > 1, b = 0.
2. a > 1, b ≠ 0.
3. а ≤ 1, b = 0.
4. a ≤ l, b ≠ 0.
5. а = 2, x > 1.
6. a = 2, x ≤ l.
7. а ≠ 2, x > 1.
8. a ≠ 2, x ≤ l.
При этом условие на значение х налагает второй оператор if. Поскольку х может быть изменено до выполнения второго оператора, то значения, необходимые для проверки, следует восстановить, исходя из логики программы для того, чтобы найти соответствующие входные значение.
Для покрытия этих восьми комбинаций достаточно 4 теста.
1. a = 2; b = 0; x = 4 a--c--e
2. a = 0; b = 0; x = 0 a--b--d
3. a = 2; b = 1; x = 0 a--b--e
4. a = 0; b = 1; x = 2 a--b--e
(Заметим, что эти 4 теста не покрывают всех путей, они пропускают путь а--с--d.)
Таким образом, для программ, содержащих только одно условие на каждое решение, минимальным является критерий набора тестов которого:
1. вызывает выполнение всех результатов каждого решения, по крайней мере, один раз
2. выполняет каждый оператор по крайней мере один раз.
Для программ содержащих более одного условия минимальный критерий состоит из набора тестов, вызывающих выполнение всех возможных комбинаций результатов условий и выполняющий каждый оператор минимум один раз.
3) Показатели эффективности программного средства
Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.
Временн(я эффективность (time efficiency)  мера, характеризующая способность ПС выполнять возложенные на него функции в течение определенного отрезка времени.
Эффективность по ресурсам (resource efficiency)  мера, характеризующая способность ПС выполнять возложенные на него функции при определенных ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency)  мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.
Билет 22
1. Понятие устойчивости программного средства.
2. ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.
Задача: Составить тесты для программы, вычисляющей ....*
1) 4 лекция
Устойчивость (robustness)  свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
2)
Постановлением Государственного комитета стандартов Совета Министров СССР от 12 января 1979 г. ¹ 74 срок введения установлен с 01.01. 1980 г.
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа "Руководство программиста", определённого ГОСТ 19.101-77.
Стандарт полностью соответствует СТ СЭВ 2095-80.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является обязательным.
1.2. Руководство оператора должно содержать следующие разделы:
* назначение программы;
* условия выполнения программы;
* выполнение программы;
* сообщения оператору.
В зависимости от особенностей документы допускается объединять отдельные разделы или вводить новые.
(Измененная редакция, Изм. № 1).
2. СОДЕРЖАНИЕ РАЗДЕЛОВ
2.1. В разделе "Назначение программы" должны быть указаны сведения о назначении программы и информация, достаточная для понимания функций программы и ее эксплуатации.
2.2. В разделе "Условия выполнения программы" должны быть указаны условия, необходимые для выполнения программы (минимальный и (или) максимальный состав аппаратурных и программных средств и т.п.).
(Измененная редакция, Изм. № 1).
2.3. В разделе "Выполнение программы" должна быть указана последовательность действий оператора, обеспечивающих загрузку, запуск, выполнение и завершение программы, приведено описание функций, формата и возможных вариантов команд, с помощью которых оператор осуществляет загрузки и управляет выполнением программы, а также ответы программы на эти команды.
(Измененная редакция, Изм. № 1).
2.4. В разделе "Сообщения оператору" должны быть приведены тексты сообщений, выдаваемых в ходе выполнения программы, описание их содержания и соответствующие действия оператора (действия оператора в случае сбоя, возможности повторного запуска программы и т.п.).
2.5. Допускается содержание разделов иллюстрировать поясняющими примерами, таблицами, схемами, графиками.
(Измененная редакция, Изм. № 1).
2.6. В приложения к руководству оператора допускается включать различные материалы, которые нецелесообразно включать в разделы руководства.
(Введен дополнительно, Изм. № 1).
Билет 23
1. Анализ граничных значений при тестировании.
2. Уровни рисков в программном проекте.
Задача: Проверить корректность спецификации программы:*
Анализ граничных значений Анализ граничных значений отличается от эквивалентного разбиение в двух моментах:
* Выбор элемента в классе эквивалентности идет таким образом, чтобы проверить тестом каждую границу этого класса * При разработке тестов рассматривается не только пространство условий, но и пространство результатов 1) Правила составления тестов 1. Построить тесты для границ области и тесты с неправильными данными для случаев незначительного выхода за границы области, если входное значение описывает диапазон значений 2. Построить тесты для минимального и максимального значения условий и тесты, большие и меньшие этих значений, если входное условие удовлетворяет дискретному ряду значений 3. Использовать правило 1 для каждого выходного условия 4. Использовать правило 2 для каждого выходного условия 5. Если вход или выход программы есть упорядоченное множество, то сделать тесты на первый и последний элементы 6. Попробовать найти другие граничные значения2) Билет 24
1. Функции программы-драйвера при тестировании. При каком тестировании применяются такие программы
2. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов.
Задача: Проверить корректность спецификации программы:*
1) При восходящем тестировании окружение содержит только один отладочный модуль, головной в тестируемой программе - ведущий (или драйвер). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и выдает необходимые сообщения. 2) ГОСТ 19.701-90
Группа Т5
Единая система программной документации
СХЕМЫ АЛГОРИТМОВ, ПРОГРАММ, ДАННЫХ И СИСТЕМ
Обозначения условные и правила выполнения
Unified system for program documentation.
Data, program and system flowcharts, program network charts and system resources charts. Documentation symbols and conventions for flowcharting
ОКСТУ 5004
ИСО 5807-85
с 01.01.92
Настоящий стандарт распространяется на условные обозначения (символы) в схемах алгоритмов, программ, данных и систем и устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения.
Стандарт не распространяется на форму записей и обозначений, помещаемых внутри символов или рядом с ними и служащих для уточнения выполняемых ими функций.
Требования стандарта являются обязательными.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Схемы алгоритмов, программ, данных и систем (далее - схемы) состоят из имеющих заданное значение символов, краткого пояснительного текста и соединяющих линий.
1.2. Схемы могут использоваться на различных уровнях детализации, причем число уровней зависит от размеров и сложности задачи обработки данных. Уровень детализации должен быть таким, чтобы различные части и взаимосвязь между ними были понятны в целом.
1.3. В настоящем стандарте определены символы, предназначенные для использования в документации по обработке данных, и приведено руководство по условным обозначениям для применения их в:
1) схемах данных;
2) схемах программ;
3) схемах работы системы;
4) схемах взаимодействия программ;
5) схемах ресурсов системы.
1.4. В стандарте используются следующие понятия:
1) основной символ - символ, используемый в тех случаях, когда точный тип (вид) процесса или носителя данных неизвестен или отсутствует необходимость в описании фактического носителя данных;
2) специфический символ - символ, используемый в тех случаях, когда известен точный тип (вид) процесса или носителя данных или когда необходимо описать фактический носитель данных;
3) схема - графическое представление определения, анализа или метода решения задачи, в котором используются символы для отображения операций, данных, потока, оборудования и т. д.
2. ОПИСАНИЕ СХЕМ
2.1. Схема данных
2.1.1. Схемы данных отображают путь данных при решении задач и определяют этапы обработки, а также различные применяемые носители данных.
2.1.2. Схема данных состоит из:
1) символов данных (символы данных могут также указывать вид носителя данных);
2) символов процесса, который следует выполнить над данными (символы процесса могут также указывать функции, выполняемые вычислительной машиной);
3) символов линий, указывающих потоки данных между процессами и (или) носителями данных;
4) специальных символов, используемых для облегчения написания и чтения схемы.
2.1.3. Символы данных предшествуют и следуют за символами процесса. Схема данных начинается и заканчивается символами данных (за исключением специальных символов, указанных в п. 3.4).
2.2. Схема программы
2.2.1 Схемы программ отображают последовательность операций в программе.
2.2.2. Схема программы состоит из:
1) символов процесса, указывающих фактические операции обработки данных (включая символы, определяющие путь, которого следует придерживаться с учетом логических условий);
2) линейных символов, указывающих поток управления;
3) специальных символов, используемых для облегчения написания и чтения схемы.
2.3. Схема работы системы
2.3.1. Схемы работы системы отображают управление операциями и поток данных в системе.
2.3.2. Схема работы системы состоит из:
1) символов данных, указывающих на наличие данных (символы данных могут также указывать вид носителя данных);
2) символов процесса, указывающих операции, которые следует выполнить над данными, а также определяющих логический путь, которого следует придерживаться;
3) линейных символов, указывающих потоки данных между процессами и (или) носителями данных, а также поток управления между процессами;
4) специальных символов, используемых для облегчения написания и чтения блок - схемы.
2.4. Схема взаимодействия программ
2.4.1. Схемы взаимодействия программ отображают путь активаций программ и взаимодействий с соответствующими данными. Каждая программа в схеме взаимодействия программ показывается только один раз (в схеме работы системы программа может изображаться более чем в одном потоке управления).
2.4.2. Схема взаимодействия программ состоит из:
1) символов данных, указывающих на наличие данных;
2) символов процесса, указывающих на операции, которые следует выполнить над данными;
3) линейных символов, отображающих поток между процессами и данными, а также инициации процессов;
4) специальных символов, используемых для облегчения написания и чтения схемы.
2.5. Схема ресурсов системы
2.5.1. Схемы ресурсов системы отображают конфигурацию блоков данных и обрабатывающих блоков, которая требуется для решения задачи или набора задач.
2.5.2. Схема ресурсов системы состоит из:
1) символов данных, отображающих входные, выходные и запоминающие устройства вычислительной машины;
2) символов процесса, отображающих процессоры (центральные процессоры, каналы и т. д.);
3) линейных символов, отображающих передачу данных между устройствами ввода - вывода и процессорами, а также передачу управления между процессорами;
4) специальных символов, используемых для облегчения написания и чтения схемы.
Примеры выполнения схем приведены в приложении.
3. ОПИСАНИЕ СИМВОЛОВ
3.1. Символы данных
3.1.1. Основные символы данных
3.1.1.1. Данные
Символ отображает данные, носитель данных не определен.
3.1.1.2. Запоминаемые данные
Символ отображает хранимые данные в виде, пригодном для обработки, носитель данных не определен.
3.1.2. Специфические символы данных
3.1.2.1. Оперативное запоминающее устройство
Символ отображает данные, хранящиеся в оперативном запоминающем устройстве.
3.1.2.2. Запоминающее устройство с последовательным доступом
Символ отображает данные, хранящиеся в запоминающем устройстве с последовательным доступом (магнитная лента, кассета с магнитной лентой, магнитофонная кассета).
3.1.2.3. Запоминающее устройство с прямым доступом
Символ отображает данные, хранящиеся в запоминающем устройстве с прямым доступом (магнитный диск, магнитный барабан, гибкий магнитный диск).
3.1.2.4. Документ
Символ отображает данные, представленные на носителе в удобочитаемой форме (машинограмма, документ для оптического или магнитного считывания, микрофильм, рулон ленты с итоговыми данными, бланки ввода данных).
3.1.2.5. Ручной ввод
Символ отображает данные, вводимые вручную во время обработки с устройств любого типа (клавиатура, переключатели, кнопки, световое перо, полоски со штриховым кодом).
3.1.2.6. Карта
Символ отображает данные, представленные на носителе в виде карты (перфокарты, магнитные карты, карты со считываемыми метками, карты с отрывным ярлыком, карты со сканируемыми метками).
3.1.2.7. Бумажная лента
Символ отображает данные, представленные на носителе в виде бумажной ленты.
3.1.2.8. Дисплей
Символ отображает данные, представленные в человекочитаемой форме на носителе в виде отображающего устройства (экран для визуального наблюдения, индикаторы ввода информации).
3.2. Символы процесса
3.2.1. Основные символы процесса
3.2.1.1. Процесс
Символ отображает функцию обработки данных любого вида (выполнение определенной операции или группы операций, приводящее к изменению значения, формы или размещения информации или к определению, по которому из нескольких направлений потока следует двигаться).
3.2.2. Специфические символы процесса
3.2.2.1. Предопределенный процесс
Символ отображает предопределенный процесс, состоящий из одной или нескольких операций или шагов программы, которые определены в другом месте (в подпрограмме, модуле).
3.2.2.2. Ручная операция
Символ отображает любой процесс, выполняемый человеком.
3.2.2.3. Подготовка
Символ отображает модификацию команды или группы команд с целью воздействия на некоторую последующую функцию (установка переключателя, модификация индексного регистра или инициализация программы).
3.2.2.4. Решение
Символ отображает решение или функцию переключательного типа, имеющую один вход и ряд альтернативных выходов, один и только один из которых может быть активизирован после вычисления условий, определенных внутри этого символа. Соответствующие результаты вычисления могут быть записаны по соседству с линиями, отображающими эти пути.
3.2.2.5. Параллельные действия
Символ отображает синхронизацию двух или более параллельных операций.
_________________________________
_________________________________
Пример.
Примечание. Процессы С, D и Е не могут начаться до тех пор, пока не завершится процесс А; аналогично процесс F должен ожидать завершения процессов В, С и D, однако процесс С может начаться и (или) завершиться прежде, чем соответственно начнется и (или) завершится процесс D.
3.2.2.6. Граница цикла
Символ, состоящий из двух частей, отображает начало и конец, цикла. Обе части символа имеют один и тот же идентификатор. Условия для инициализации, приращения, завершения и т. д. помещаются внутри символа в начале или в конце в зависимости от расположения операции, проверяющей условие.
Пример.
3.3. Символы линий
3.3.1 .Основной символ линий
3.3.1.1. Линия
Символ отображает поток данных или управления.
___________________________
При необходимости или для повышения удобочитаемости могут быть добавлены стрелки - указатели.
3.3.2. Специфические символы линий
3.3.2.1. Передача управления
Символ отображает непосредственную передачу управления от одного процесса к другому, иногда с возможностью прямого возвращения к инициирующему процессу после того, как инициированный процесс завершит свои функции. Тип передачи управления должен быть назван внутри символа (например, запрос, вызов, событие).
3.3.2.2. Канал связи
Символ отображает передачу данных по каналу связи.
3.3.2.3. Пунктирная линия
Символ отображает альтернативную связь между двумя или более символами. Кроме того, символ используют для обведения аннотированного участка.
Пример 1.
Если один из ряда альтернативных выходов используют в качестве входа в процесс либо когда выход используется в качестве входа в альтернативные процессы, эти символы соединяют пунктирными линиями.
Пример 2.
Выход, используемый в качестве входа в следующий процесс, может быть соединен с этим входом с помощью пунктирной линии.
3.4. Специальные символы
3.4.1. Соединитель
Символ отображает выход в часть схемы и вход из другой части этой схемы и используется для обрыва линии и продолжения ее в другом месте. Соответствующие символы - соединители должны содержать одно и то же уникальное обозначение.
3.4.2. Терминатор
Символ отображает выход во внешнюю среду и вход из внешней среды (начало или конец схемы программы, внешнее использование и источник или пункт назначения данных).
3.4.3. Комментарий
Символ используют для добавления описательных комментариев или пояснительных записей в целях объяснения или примечаний. Пунктирные линии в символе комментария связаны с соответствующим символом или могут обводить группу символов. Текст комментариев или примечаний должен быть помещен около ограничивающей фигуры.
Пример.
3.4.4. Пропуск
Символ (три точки) используют в схемах для отображения пропуска символа или группы символов, в которых не определены ни тип, ни число символов. Символ используют только в символах линии или между ними. Он применяется главным образом в схемах, изображающих общие решения с неизвестным числом повторений.
Пример.
4. ПРАВИЛА ПРИМЕНЕНИЯ СИМВОЛОВ И ВЫПОЛНЕНИЯ СХЕМ
4.1. Правила применения символов
4.1.1. Символ предназначен для графической идентификации функции, которую он отображает, независимо от текста внутри этого символа.
4.1.2. Символы в схеме должны быть расположены равномерно. Следует придерживаться разумной длины соединений и минимального числа длинных линий.
4.1.3. Большинство символов задумано так, чтобы дать возможность включения текста внутри символа. Формы символов, установленные настоящим стандартом, должны служить руководством для фактически используемых символов. Не должны изменяться углы и другие параметры, влияющие на соответствующую форму символов. Символы должны быть, по возможности, одного размера.
Символы могут быть вычерчены в любой ориентации, но, по возможности, предпочтительной является горизонтальная ориентация. Зеркальное изображение формы символа обозначает одну и ту же функцию, но не является предпочтительным.
4.1.4. Минимальное количество текста, необходимого для понимания функции данного символа, следует помещать внутри данного символа. Текст для чтения должен записываться слева направо и сверху вниз независимо от направления потока.
Пример.
Если объем текста, помещаемого внутри символа, превышает его размеры, следует использовать символ комментария.
Если использование символов комментария может запутать или разрушить ход схемы, текст следует помещать на отдельном листе и давать перекрестную ссылку на символ.
4.1.5. В схемах может использоваться идентификатор символов. Это связанный с данным символом идентификатор, который определяет символ для использования в справочных целях в других элементах документации (например, в листинге программы). Идентификатор символа должен располагаться слева над символом.
Пример.
4.1.6. В схемах может использоваться описание символов - любая другая информация, например для отображения специального применения символа с перекрестной ссылкой, или для улучшения понимания функции как части схемы. Описание символа должно быть расположено справа над символом.
Пример.
4.1.7. В схемах работы системы символы, отображающие носители данных, во многих случаях представляют способы ввода - вывода. Для использования в качестве ссылки на документацию текст на схеме для символов, отображающих способы вывода, должен размещаться справа над символом, а текст для символов, отображающих способы ввода , - справа под символом.
Пример.
4.1.8. В схемах может использоваться подробное представление, которое обозначается с помощью символа с полосой для процесса или данных. Символ с полосой указывает, что в этом же комплекте документации в другом месте имеется более подробное представление.
Символ с полосой представляет собой любой символ, внутри которого в верхней части проведена горизонтальная линия. Между этой линией и верхней линией символа помещен идентификатор, указывающий на подробное представление данного символа.
В качестве первого и последнего символа подробного представления должен быть использован символ указателя конца. Первый символ указателя конца должен содержать ссылку, которая имеется также в символе с полосой.
4.2. Правила выполнения соединений
4.2.1. Потоки данных или потоки управления в схемах показываются линиями. Направление потока слева направо и сверху вниз считается стандартным.
В случаях, когда необходимо внести большую ясность в схему (например, при соединениях), на линиях используются стрелки. Если поток имеет направление, отличное от стандартного, стрелки должны указывать это направление.
4.2.2. В схемах следует избегать пересечения линий. Пересекающиеся линии не имеют логической связи между собой, поэтому изменения направления в точках пересечения не допускаются.
Пример.
4.2.3. Две или более входящие линии могут объединяться в одну исходящую линию. Если две или более линии объединяются в одну линию, место объединения должно быть смещено.
Пример.
4.2.4. Линии в схемах должны подходить к символу либо слева, либо сверху, а исходить либо справа, либо снизу. Линии должны быть направлены к центру символа.
4.2.5. При необходимости линии в схемах следует разрывать для избежания излишних пересечений или слишком длинных линий, а также, если схема состоит из нескольких страниц. Соединитель в начале разрыва называется внешним соединителем, а соединитель в конце разрыва - внутренним соединителем.
4.2.6. Ссылки к страницам могут быть приведены совместно с символом комментария для их соединителей.
Пример.
4.3. Специальные условные обозначения
4.3.1 .Несколько выходов
4.3.1.1. Несколько выходов из символа следует показывать:
1) несколькими линиями от данного символа к другим символам;
2) одной линией от данного символа, которая затем разветвляется в соответствующее число линий.
Примеры.
4.3.1.2. Каждый выход из символа должен сопровождаться соответствующими значениями условий, чтобы показать логический путь, который он представляет, с тем, чтобы эти условия и соответствующие ссылки были идентифицированы.
Примеры.
4.3.2. Повторяющееся представление
4.3.2.1. Вместо одного символа с соответствующим текстом могут быть использованы несколько символов с перекрытием изображения, каждый из которых содержит описательный текст (использование или формирование нескольких носителей данных или файлов, производство множества копий печатных отчетов или форматов перфокарт).
4.3.2.2. Когда несколько символов представляют упорядоченное множество, это упорядочение должно располагаться от переднего (первого) к заднему (последнему).
4.3.2.3. Линии могут входить или исходить из любой точки перекрытых символов, однако требования п. 4.2.4 должны соблюдаться. Приоритет или последовательный порядок нескольких символов не изменяется посредством точки, в которой линия входит или из которой исходит.
Пример.
5. ПРИМЕНЕНИЕ СИМВОЛОВ
СимволНаимено-
вание
символаСхема данныхСхема програм-
мыСхема работы системыСхема взаимо-
дейст-
вия прог-
раммСхема ресур-
сов систе-
мыСимволы данных Основные Данные+++++ Запоми-
наемые
данные+-+++Специфические Оператив-
ное запоми-
нающее
устройство+-+++ Запоми-
нающее
устройство
с последо-
вательной выборкой+-+++ Запоминающее устройство
с прямым
доступом+-+++ Документ+-+++ Ручной
ввод+-+++ Карта+-+++ Бумажная
лента+-+++ Дисплей+-+++Символы процесса Основные Процесс+++++Специфические Предопре-
деленный процесс-+++- Ручная
операция+-++- Подготовка++++- Решение-++-- Параллельные действия-+++- Граница цикла-++--Символы линий Основные Линия+++++Специфические Передача управления---+- Канал связи+-+++ Пунктир-
ная линия+++++Специальные символы Соединитель+++++ Терминатор+++-- Комментарии+++++ Пропуск+++++Примечание. Знак "+" указывает, что символ используют в данной схеме, знак "-" - не используют.
ПРИЛОЖЕНИЕ
Справочное
ПРИМЕРЫ ВЫПОЛНЕНИЯ СХЕМ
1. Схема данных
2. Схемы программы
Пример 1.
Пример 2.
3. Схема работы системы
4. Схема взаимодействия программ
5. Схема ресурсов системы
Билет 25
1. Функции программы-заглушки при тестировании. При каком тестировании применяются такие программы
2. ГОСТ 19.701-90 ЕСПД. Схемы программ.
3. ЗАДАЧА: Проверить корректность спецификации программы:*
1) Каждый имитатор модуля (заглушка) представляется весьма простым программным фрагментом, который, в основном, сигнализирует о самом факте обращения к имитируемому модулю, производит необходимую для правильной работы программы обработку значений его входных параметров (иногда с их распечаткой) и выдает, если это необходимо, заранее запасенный подходящий результат.
Применяются заглушки при нисходящем тестировании.
2)
Документ
Категория
Разное
Просмотров
343
Размер файла
749 Кб
Теги
шпаргалки, ответытрпо, шпоры
1/--страниц
Пожаловаться на содержимое документа