Электронные библиотеки и инструментарий Internet’a

1. Коллекции информационных ресурсов;

2. БД Интернета;

3. Поисковые средства;

4. Системы AI (мультиагенты).

7. Репозитории.

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

Три уровня репозитория:

• Модельный;

• Программного интерфейса;

• Окружения.

8. Средства поддержки коллективной разработки

Проблема разделения ресурсов.

1. Системы разделения файлов.

   1. Системы управления версиями файлов (для отслеживания изменений между версиями файлов и разделения доступа к ним).

   2. Системы управления правами пользователей (для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве). Мастер пространство.

   3. Системы синхронизации удаленных производств. Решаются проблемы организации и пересылки изменений и их синхронизации.

2. Средств поддержки работы виртуальных групп.

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

12.Способы описания алгоритмов

Разработка алгоритмов является неотъемлемой составляющей процесса программирования.

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

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

Для описания алгоритмов используются следующие способы:

1. Словесный – описание осуществляется на естественном языке.

2. Граф-схема – состоит из вершин (операторов, выполняемых в этой вершине) и дуг, указывающих последовательность выполнения операторов.

3. Логическая схема – операторы записываются в строку слева направо в порядке их естественного выполнения. При выполнении условных операторов альтернативные переходы показываются стрелкой.

4. Матричная схема – используется матрица К*К, где К – число всех операторов. На пересечении строки и столбца указывается 1, если за оператором в строке следует оператор столбца.

5. Р-схема – нагруженный по дугам ориентированный граф, изображаемый с помощью вертикальных и горизонтальных линий и состоящий из структур (подграфов), каждый из которых имеет только 1 вход и 1 выход (ГОСТ 19.005-85)

6. Блок-схема – схема, использующая символы для отображения операций, данных, потока, оборудования и т.д. Правила выполнения схем алгоритмов программ, данных и систем представлены в ГОСТ 19.701 – 90.

7. Алгоритмический язык (псевдокоды) – язык записи структурированных алгоритмов, использующий некоторое ограниченное число слов родного языка программиста.

8. Языки программирования – окончательная запись алгоритма в виде, пригодном для исполнения компьютером.

Представлению процедурных алгоритмов посвящен также стандарт ГОСТ Р ИСО/МЭК 8631-94 «Программные конструктивы и условные обозначения для их представления»(введен 1995—07—01). Он содержит полный текст международного стандарта ИСО/МЭК 8631-94 «Информационная технология. Программные конструктивы и условные обозначения для их представления». В стандарте представлены конструктивы, принятые в разных странах, в том числе для сравнения приводятся конструктивы в соответствии с ГОСТ 19.701—90.

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

13. Стиль программирования

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

Одним из методов улучшения стиля являются комментарии.

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

Можно выделить вводные, оглавления и пояснительные комментарии.

Минимальная информация вводных комментариев: 1. Назначение программы; 2. Указания по вызову программы и ее использованию; 3. Список и назначение основных переменных или массивов; 4. Указания по вводу-выводу. Список всех файлов; 5. Список используемых подпрограмм; 6. Название применяемых математических методов, а также ссылки на литературные источники, где содержится их описание; 7. Сведения о времени выполнения программы; 8. Требуемый объем памяти; 9. Специальные указания оператору; 10. Сведения об авторе; 11. Дату написания программы.

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

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

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

Методом улучшения наглядности программ является пропуск строк и использование пробелов.

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

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

Ряд требований предъявляется к оформлению.

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

Одного оператора в строке достаточно (выше удобочитаемость программы; легче выделить разделы; легче обнаружить ошибки, т.к. в сообщении об ошибке указывается №строки). Скобки следует ставить во всех сомнительных случаях.

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

Одинаковый отступ от начала строки указывает на связь между операторами. Используется для групп типа BEGIN … END, циклов, группировки команд, операторов IF, ввода-вывода, записи вложенных процедур. Отступы используются для выявления структуры данных и структуры программы.

Залогом удобочитаемости программ является правильный выбор идентификаторов.

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

При наименовании файлов рекомендуется взять определенный префикс или суффикс. Его можно использовать в названии младших единиц этого файла. Желательно, чтобы имена файлов содержали слово FILE, а имена записей – RECORD. Указанный прием позволяет различать по префиксам идентичные имена, такие, как поля дат, например: MASTER-DATE, TRANS-DATE, REPORT-DATE. При выборе имен записей имена следует ориентиро­вать на содержание записи, а не на конкретное задание.

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

Следует избегать схожих по виду имен, их неестественных написаний (как phone и fone); подобных по написанию символов (АХ10 и АХIO); употребле­ния слов, которые могут ввести в заблуждение пользователя программы. При использовании различных типов переменных: целых, действительных, символьных – полезно начинать их имена с определенных символов. Например, с С – для комплексных; с I, J, K, L, M, N – для целых.

Числа лучше писать в конце имени переменных. Рекомендуется использовать одну или две цифры метки для идентификации блока, а остальные – для нумерации опе­раторов внутри блока. Чтобы иметь возможность независимого выбора имени параграфов, добавляйте к мнемоническим именам параграфов их номера в порядке следования. Например, имена TEST-LOOP-600, RUN-ERROR-610, REPORT-OUT-620 указывают относительное расположение параграфов в программе. Номера должны предусматривать включение новых параграфов.

При отсутствии ограничения на длину имени, предпочтительны длинные имена, но не длиннее, чем необходимо. Если язык программирования допускает разделитель в именах переменных, его следует использовать: COST-PLUS лучше, чем COSTPLUS.

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

Правила сокращения разработаны Микаэлом Джексоном 1967:

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

2. В аббревиатуру всегда должны включаться начальные буквы слов.

3. Согласные важнее гласных.

4. Начало слова важнее его конца.

5. Аббревиатура должна включать в себя от 6 до 15 букв.

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

14.Архитектурная платформа

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

Классификация архитектур:

1. По элементной базе (поколения)

   1. Кто на чем;

   2. Вакуумные лампы;

   3. Транзисторы;

   4. На интегральных схемах;

   5. Микропроцессоры;

2. По функциональному назначению

   1. Массивно-параллельные системы;

   2. Кластерная архитектура;

   3. СуперЭВМ;

   4. Мэйнфреймы;

   5. Миникомпьютеры;

   6. Рабочие станции;

   7. Терминалы;

   8. ПК;

   9. и др.

3. По степени централизации

   1. Централизованные (одно- и многомерные);

   2. Сетевые;

   3. Распределенные;

4. По организации потоков команд и данных

   1. SISD (одиночный поток команд и одиночный поток данных);

   2. SIMD (одиночный поток команд и множественный поток данных);

   3. MISD (множественный поток команд и одиночный поток данных);

   4. MIMD (множественный поток команд и множественный поток данных);

5. По архитектуре набора команд

   1. Фон-Неймановская архитектура:

      • Последовательно адресуемая память, линейная и одномерная;

      • Отсутствует явное различие между командами и данными; их идентифицируют неявным способом при выполнении операции;

      • Назначение данных определяется логикой программы.

   2. Аккумулятор ≈ простейший калькулятор

Процессор имеет единственный регистр, называемый аккумулятором, содержимое которого комбинируется в АЛУ CPU с единственным операндом. Результат помещается в аккумулятор;

3. Стековая

Арифметические операции не имеют операндов. Оба операнда берутся с вершины стека и результат помещается на вершину стека.

4. Регистр-Регистр.

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

5. Компьютер с полным набором команд (CISC-16).

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

6. Архитектура с сокращенным набором команд (RISC).

Одинаковая длина команд, единый формат команд, большой регистровый файл. Любая команда выполняется за 1 такт.

7. Архитектура с длинным командным словом.

8. Архитектура с явным параллелизмом команд

Перспективные направления

1. Квантовые компьютеры.

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

2. Нейрокомпьютеры (биокомпьютеры)

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

3. Оптические компьютеры. Обрабатывают информацию с использованием света.

15.Операционная платформа

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

Основные функции ОС

• Загрузка пользовательских программ в оперативную память для выполнения;

• Управление памятью;

• Работа с устройствами дополнительной памяти;

• Предоставление доступа к периферийным устройствам;

• Предоставление пользовательского интерфейса;

Классификация ОС

1. По времени создания (поколение)

0. ОС отсутствует;

1. Пакетная обработка. Мультипрограммные ОС;

2. Многорежимные ОС. ОС реального времени;

3. ОС для ПК; сетевые ОС;

4. Распределенные ОС;

2. По степени централизации

   1. Централизованные или локальные;

   2. Сетевые;

   3. Распределенные

3. Распределенные ОС (предоставляют пользователю единую централизованную виртуальную машину с максимальной степенью прозрачности сетевых ресурсов, объединяющую все компьютеры сети для работы в тесной кооперации).

Особенности алгоритмов управления ресурсами отражаются в классификации:

1. Многозадачные и однозадачные;

2. Однопользовательские и многопользовательские;

3. Однопоточные и многопоточные;

4. Однопроцессорные и многопроцессорные;

По особенностям областей использования (по режиму разделения времени):

1. ОС пакетной обработки (работают с пакетами задач). Переключение на следующую задачу происходит в том случае, если сама текущая задача отказалась от процессора.

2. ОС разделения времени (каждая задача получает квант процессорного времени). Работа в диалоговом режиме. Вмешательство пользователя.

3. ОС реального времени (для управления технологическими процессами). Более жесткие требования по реакции программы на команды. Устанавливаются предельно допустимые интервалы времени.

Структура ос

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

По типу архитектуры ядра ОС делятся на:

1. ОС с монолитным ядром. Ядро – одна программа, работающая в привилегированном режиме.

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

3. ОС с микроядром. Микроядро выполняет минимум функций по управлению аппаратурой (обычно реализуется на ассемблере, т.е. они являются машинно-зависимыми). Выполняет некоторые функции управления процессами и обработкой прерываний. Система клиент-сервер.

4. ОС с экзоядром. Позволяет собрать ОС с использованием большой библиотеки функций. В ядре реализованы лишь минимально необходимые функции для реализации этой сборки и взаимодействия программ.

По количеству и качеству реализуемых функций ОС делятся на:

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

ОС – DOS.

2. ОС общего назначения. Максимум функций, рассчитаны на интерактивную работу одного или нескольких пользователей в режиме разделения времени. Требования ко времени реакции системы не предъявлены (минимальны). Защита пользовательских данных.

ОС – UNIX, Windows 2000+.

3. Системы виртуальных машин. Допускают одновременную работу нескольких программ. Характерен режим разделения времени.

ОС – Window и др.

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

5. Системы кросс-разработки. Для разработки программ двухмашинной конфигурации.

6. Системы промежуточных типов. Все остальные.

По родственным связям ОС делятся на:

1. Семейство ОС для больших компьютеров

ОС: OS/390, IBM VM;

2. Семейство Unix;

3. CP/M.

В настоящее время доминируют 2 класс ОС:

• Windows. На персональных компьютерах, в сетях, на клиентских компьютерах. Удобный графический интерфейс. Пользователи – от новичков до профессионалов. (-) – ненадежны;

• UNIX. На мощных серверах и рабочих станциях. Используются в качестве серверной ОС. Предназначены в основном для профессионалов. Основная цель – создание окружения, удобного для развития программ.

(+) – достаточно надежны.

Томпсон и Ритчи.

Выбор ОС зависит от предъявляемых требований и часто является нетривиальной задачей. Пример:

• Задача управления промышленным или исследовательским оборудованием заставляют делать выбор между специализированными ОС реального времени и некоторыми ОС общего назначения, которые тоже позволяют выполнить эти работы.

• Задача автоматизации конторской работы не предъявляется особых требований к надежности, производительности и времени реакции системы.

Одной из проблем ряда ОС является их закрытость. Альтернативным решением по отношению к закрытым платформам (фирменный интерфейс) является концепция открытых систем. Эту задачу предлагают решить с помощью открытых стандартов:

• Стандартные сетевые протоколы (TCP/IP);

• Стандартные форматы данных (пока единого формата нет);

• Стандартные интерфейсы (один из первых – стандарт ANSI).

16.Тестирование и отладка.

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

Функции тестирования:

Обнаружение ошибок.

Демонстрация соответствия функций программы ее назначению.

Демонстрация реализации требований к характеристикам программы.

Отображение надежности программного средства.

Информационные потоки тестирования можно представить следующим образом:

Рисунок.

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

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

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

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

Основные принципы тестирования:

1. Известные результаты тестирования.

2. Избегать тестирования автором

3. Необходимо изучить результаты каждого теста.

4. Проверять действие на неверных данных.

5. Проверять на неожиданные эффекты при побочных данных.

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

Отладка.

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

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

Отладка = тестирование + поиск ошибок + их исправление.

Отладка – самый сложный этап создания ПО.

Сложность отладки обусловлена:

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

2. Психологический дискомфорт: поиск собственных ошибок в ограниченное время.

3. Возможно взаимовлияние ошибок в разных частях программы.

4. Отсутствие четко сформулированных методов отладки.

То есть при подготовке тестирования и отладки перед разработчиком возникает 2 задачи:

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

2. определение момента окончания отладки. Признаком возможности завершения могут быть относительно редкое появление ошибок в ПО на последнем отрезке процесса тестирования.

Виды ошибок.

По этапу обработки:

Ошибки компиляции.

Ошибки компоновки.

Ошибки выполнения.

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

2. Ошибки компоновки – ошибки обнаруженные компоновщиком при объединении модулей. Связаны с проблемами при разрешении внешних ссылок.

3. Ошибки выполнения – самая непредсказуемая группа. Проявляются в виде появления сообщений об ошибке, зафиксированной схемой контроля выполнения машинных команд (переполнение разрядной сетки, деление на 0); Появление сообщений об ошибке, обнаруженной ОС (нарушение защиты памяти, попытка записи на защищенное устройство; зависание компьютера, как простое, так и тяжелое, несовпадение полученных результатов с ожидаемыми).

Причины появления ошибок выполнения:

1. Неверное определение исходных данных. Происходит, если возникают ошибки передачи, ошибки преобразования, ошибки перезаписи, ошибки данных, ошибки ввода-вывода.

2. Логические ошибки:

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

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

- ошибки вычисления: неправильное использование целочисленной арифметики, преобразование типов, нарушение приоритетов.

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

- неправильная реализация алгоритмов и др.

3. Ошибки накопления погрешности результатов числовых вычислений. Возникают при игнорировании ограничений разрядной сетки (отбрасывание сотых разрядов и др.).

Существуют другие классификации:

- ошибки общего вида.

- ошибки специального вида.

Отслеживание ошибок:

1. Ошибка должна быть зарегистрирована;

2. Выполнение первичного анализа.

3. Выявление причины ошибки.

4. Окончательный анализ ошибки.

5. Принятие решения о работе над исправлением ошибки.

6. Исправление ошибки.

7. Интегрирование исправления в основное пространство.

8. Подтверждение исправления ошибки.

Методы и виды тестирования.

1. По цели тестирования:

   1. выявления факта наличия ошибки.

   2. локализация ошибки, выявление причины.

   3. аттестация программного средства.

2. По виду программного документа, на основе которого строятся тесты:

   1. автономное: нисходящее, восходящее.

   2. комплексное:

      1. тестирование архитектуры.

      2. тестирование внешних функций.

      3. тестирование качества ПС.

      4. тестирование документации.

      5. определение требований.

3. По стратегии проектирования тестов:

   1. белого ящика.

   2. оптимальное (серого ящика).

   3. черного ящика.

4. По способу формирования наборов тестовых данных:

   1. детерминированное.

   2. случайное.

5. По направленности тестирования:

   1. статическое.

   2. динамическое.

6. По способу реализации:

   1. ручное

      1. инспекция исходных текстов;

      2. сквозные просмотры;

      3. проверка за столом;

      4. оценка правильности.

   2. выполнение

      1. тестирование маршрутов.

         1. покрытие операторов;

         2. покрытие решений;

         3. покрытие условий;

         4. покрытие решений/условий;

         5. комбинаторное покрытие циклов;

      2. тестирование потоков данных;

      3. Тестирование циклов

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

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

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

Достоинство восходящего тестирования:

• простота подготовки тестов;

• возможность полной реализации плана тестирования.

Недостатки восходящего тестирования:

• тестовые данные готовятся не в той форме, которая рассчитана на пользователя (исключение – головной модуль).

• большой объем отладочного программирования.

• необходимость специального тестирования сопряжения модулей.

Достоинства нисходящего тестирования:

• тесты в форме рассчитанной на пользователя;

• во многих случаях небольшой объем отладочного программирования;

• опадает необходимость тестирования сопряжения модулей.

Недостатки нисходящего тестирования:

• тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно.

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

Этапы автономного тестирования:

1. На основе спецификации модуля готовят тест для всех возможностей и ситуаций, для всех допустимых значений входных данных, для каждой области изменения входных данных, а также для недопустимых значений данных и условий.

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

3. Проверка текста модуля с целью выявления наличия тестов для всех циклов и следующих ситуаций:

а) тело цикла не выполняется ни разу,

б) тело цикла выполняется 1 раз,

в) выполняется max число раз.

+ разработка недостающих тестов.

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

Комплексное тестирование.

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

Тестирование архитектуры.

Цель – поиск несоответствия между описанием архитектуры и совокупностью программ. Выполняется после автономной отладки каждой подсистемы. Проверяются все пути взаимодействия между подсистемами.

Тестирование внешних функций.

Цель – поиск расхождения между функциональной спецификацией и совокупностью программ ПС. Тестирование функций чаще производится методом черного ящика.

Тестирование качества.

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

Тестирование документации по применению.

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

Тестирование определения требований к ПС.

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

17.Стандартные технологические процессы

Стандарт выделяет 3 группы процессов жизненного цикла:

4. Основные;

5. Вспомогательные;

6. Организационные.

4. Основные

   1. Процесс заказа (приобретение).

   2. Процесс поставки.

   3. Процесс разработки

      1. Подготовительная работа (выбор модели жизненного цикла, стандартов, методов, средств разработки, составление плана работы).

      2. Анализ требований к системе (функциональность, надежность, безопасность, интерфейс).

      3. Проектирование архитектуры системы (не только ПО, но и всего комплекса).

      4. Анализ требований к ПО.

      5. Проектирование архитектуры ПО.

      6. Детальное проектирование ПО (модули).

      7. Кодирование и тестирование ПО.

      8. Интеграция ПО.

      9. Квалификационное тестирование ПО.

      10. Интеграция системы.

      11. Квалификационное тестирование системы (в том числе документации).

      12. Установка ПО на оборудование заказчика.

      13. Приемка ПО.

   4. Процесс эксплуатации (работа оператора).

   5. Процесс сопровождения.

Вспомогательные процессы

-Процесс документирования - предполагает формализованное описание информации, созданной в процессе жизненного цикла.

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

Заинтересованные лица: администраторы, инженеры, пользователи.

-Процесс управления конфигурацией - является процессом применения административных и технических процедур на всем протяжении жизненного цикла программных средств:

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

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

описание и сообщение о состоянии объектов и заявок на внесение изменений в них;

обеспечение полноты, совместимости и правильности объектов;

для управления хранением, обращением и поставкой объектов.

-Процесс обеспечения качеством

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

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

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

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

-Процесс верификации

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

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

-Аттестация

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

Аттестация независимая, если исполнитель не зависит от поставщика, разработчика, оператора или персонала сопровождения.

-Процесс совместного анализа

Является процессом оценки состояния и результатов работ по проекту.

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

-Процесс аудита

Является процессом определения соотвествия требованиям, планам и условиям договора. Выполняется двумя сторонами (ревизирующей и ревизируемой), участвующими в договоре.

-Процесс решения проблем

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

Организационные процессы

-Процесс управления

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

Список работ процесса управления:

--подготовка и опедедение области управления

--планирование

--выполнение и контроль.

-Процесс создания инфраструктуры

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

-Процесс усовершенствования

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

-обучение

процесс обеспечения первоначального и продолжительного обучения персонала (речь не идет об обучении пользователей, а идет об обучении разработчиков)

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

Список работ:

--подготовка

--разработка учебных материалов

--реализация плана обучения

18. Документирование

Качество программного обеспечения, наряду с другими факторами, определяется полнотой и качеством пакета документов, сопровождающих программное обеспечение (ПО) К программным документам относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения программ и их эксплуатации. Документирование программного обеспечения регламентируется стандартами ГОСТ серий 19 и 34, ГОСТ Р ИСО/МЭК 8631, ГОСТ Р ИСО 9127, ГОСТ Р ИСО/МЭК ТО 9294 и некоторыми другими. Полный перечень нормативных документов на программную документацию приведен в документе «Методика экспертизы программной документации» находящегося на стадии утверждения.

ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология. Руководство по управлению документированием программного обеспечения» является одним из основных стандартов в данной области и представляет собой руководство по документированию ПО для тех руководителей, которые отвечают за производство программного обеспечения или программной продукцию. Данный стандарт направлен на определение стратегий, стандартов, процедур, ресурсов и планов, которыми должны заниматься сами руководители для того, чтобы эффективно управлять документированием ПО. Руководство предназначено для применения ко всем типам программного обеспечения - от простейших программ до наиболее сложных систем программного обеспечения, охватывающих все типы программной документации, относящейся ко всем стадиям жизненного цикла ПО. Для небольших проектов значительную часть положений, приведенных в данном стандарте, можно не применять, но принципы управления документированием остаются теми же.

В ГОСТ Р ИСО/МЭК ТО 9294-93 программная документация рассматривается как имеющая следующие шесть основных функций.

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

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

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

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

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

6. Исторические справки. Документация, требуемая в качестве исторической справки по проекту. Данная документация может помочь в переносе и переводе ПО в новое окружение.

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

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

2) документирование должно быть управляемым;

3) документация должна соответствовать ее читательской аудитории;

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

5. должны быть определены и использованы стандарты по документированию;

6. должны быть определены средства поддержки.

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

Программные документы можно представить разделенными на три категории (данная схема служит контрольной таблицей основных типов программных документов, которые руководители должны предусмотреть, когда определяют стандартные типы своих документов):

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

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

б) они описывают обязанности группы разработки и каждого ее участника;

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

г) они образуют основу документации сопровождения ПО;

д) они описывают историю разработки ПО.

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

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

Документация продукции преследует три цели:

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

• облегчение сопровождения и модернизации ПО программистам, не разрабатывавших ПО;

• помощь при продаже или приемке ПО.

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

Типовые документы продукции включают в себя: учебные руководства; справочные руководства и руководства пользователя; руководства по сопровождению ПО; брошюры и информационные листки, посвященные продукции.

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

ГОСТ Р ИСО 9127-94 «Системы обработки информации. Документация пользователя и информация на упаковке для потребительских пакетов» вводит определение документации пользователя, как документации, которая обеспечивает пользователей информацией, необходимой для установки и прогона ПО и является обязательной в поставке (документация пользователя выполняется в виде одного или нескольких руководств и вкладывается вместе с программным продуктом внутрь упаковки). Назначением документации пользователя является обеспечение конечного пользователя достаточной информацией для ясного понимания цели, функций и характеристик ПО; того, как ввести в действие и использовать ПО; договорных прав и обязанностей.

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

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

• обязательная - информация, поставляемая с каждым пакетом;-

• условная - информация, поставляемая с каждым пакетом, для которого она необходима;

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

Таким образом, ГОСТ Р ИСО 9127, не имея формальных ссылок на ГОСТ Р ИСО/МЭК ТО 9294, фактически дополняет введенное в нем понятие документации продукции.

19-я система стандартов (Единая система программной документации - ЕСПД) устанавливает следующие виды программной документации.

1. Спецификация. Состав программы и документация на нее.

2. Ведомость держателей подлинников. Перечень предприятий, на которых хранят подлинники программных документов.

3. Текст программы. Запись программы с необходимыми комментариями.

4. Описание программы. Сведения о логической структуре и функционировании программ.

5. Программа и методика испытаний. Требования, подлежащие проверке при испытании программы, а также порядок и методы контроля.

6. Техническое задание. Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний.

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

8. Эксплуатационные документы. Сведения для обеспечения функционирования и эксплуатации программы. Перечень эксплуатационных документов представлен в таблице 1.

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

ГОСТ 34.602-89 - техническое задание на создание АС;

ГОСТ 34.201-90 - виды и комплектность документов;

РД 50-34.698-90 - пояснительная записка, схема функциональной структуры,

Таблица 1.

Перечень эксплуатационных документов

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

ГОСТ 19.201-78 - техническое задание;

ГОСТ 19.402-78 - описание программы;

ГОСТ 19.404-79 - пояснительная записка;

ГОСТ 19.301-79 - программа и методика испытаний.

19. Спецификация качества пс

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

Примитивы:

1. функциональность - выражается через завершенность.

2. надежность - завершенность, точность, автономность, устойчивость, защищенность.

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

4. эффективность - временная эффективность, эффективность по ресурсам (памяти), эффективность по устройствам.

5. сопровождаемость:

а) изучаемость: С- документированность, информативность, понятность, структурированность, удобочитаемость.

б) модифицируемость: расширяемость, модифицируемость, структурированность, модульность.

6. Мобильность - независимость от устройств, автономность, структурированность, модульность.

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

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

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

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

11. Защищенность – способность ПС противостоять преднамеренным или нечаянным деструктивным действиям пользователя.

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

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

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

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

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

17. Эффективность по устройствам – экономичность использования устройств (машины для решения поставленной задачи).

18. С- документированность – свойство, характеризующее ПС с точки зрения наличия документации, отражающей требования к ПС, результатов различных этапов разработки данного ПС (в том числе возможные ограничения и т.п. и их обоснование, документы сопровождения) С-«сопровождение».

19. Понятность – свойство, характеризующее степень, с которой ПС позволяет изучающему его лицу понять его назначение, ограничения и допущения и т.п. (является синтезом согласованности, С- документированности, четкости и понятности текстов программы).

20. Структурированность – характеризует ПС с точки зрения организации взаимосвязанных частей в единое целое.

21. Удобочитаемость – характеризует легкость восприятия текста программы.

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

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

24. Модульность – характеризует ПС с точки зрения организации его программ из таких дискретных компонентов, что изменение одной из них оказывает минимальное влияние на другие компоненты.

25. Независимость от устройств – характеризует способность ПС работать на разнообразном виде аппаратуры.

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

На основе структурной методологии для анализа требований проектирования могут быть применены следующие системы:

Silverrim Model Sphere

Oracle Designer

Erwin

ДРАКОН

CASE средства

На основе объектно-ориентированной методологии:

Rational Rose

Together Control Center

В процессе программирования – трансляторы.

Разновидности трансляторов: компиляторы, декомпиляторы, интерпретаторы.

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

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

Интерпретатор – непосредственное исполнение текста.

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

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

Существует ряд декомпиляторов:

Mocha, Crema, Sourse Tee Java Decompiler, Jad.

Помимо трансляторов применяются системы генерации трансляторов.

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

1. LL(n)

Анализаторы построены по принципу снизу-вверх: SYNTAX, DEPOT, LLGEN.

2. LR(n)

Анализаторы построены по принципу сверху-вниз: BISON, PSYACC.

Системы анализа корректности программного кода – близки к системам синтаксического анализа. Разрабатываются для языков со слабым контролем типов и выполняют большее количество проверок, чем стандартные анализаторы. К ним относятся: Lint, PCLint, FlereLint.

В связи с развитием программ декомпиляции существуют программы шифраторы.

(?)

усложнители декомпиляции:

- общее усложнение.

- целенаправленное усложнение (против конкретного декомпилятора).

Основная идея - в ухудшении кода

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

Инструментарий, применяемый для тестирования и отладки.

1. Тестовые мониторы. Включают:

- ядро (программа тестирования и оформления результатов).

- тестовая база (исходный тест и результаты).

- тестовое пространство.

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

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

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

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

6. Система отслеживания проблем (ошибок). Представляет собой интерфейс к базе данных, в которой хранится информация, связанная с ошибкой. Информация включает:

a. основную информацию об ошибке (номер, краткое описание, ключевые слова, приоритеты, состояние);

b. место проявления ошибки (программный продукт, версия, компонент, особенность);

c. персоналии (кто может иметь отношение, ответственный менеджер, инженер и др.);

d. анализ и исправление;

e. влияние исправления

22. Универсальный;

Универсальный инструментарий. Программа представляет собой текст.

Группы:

2. Инструменты работы с текстом (редакторы, средства поиска).

   1. Средства, базирующиеся на регулярных выражениях.

Для поиска участков текста по некоторым конкретным шаблонам.

2. Средства поиска различий (для обнаружений разницы между фрагментами)

diff, GNUdiff.

3. Средства поиска на основе шаблона.

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

4. Обозреватели БД программ.

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

Omega, CLA

5. Средства обнаружения плагиата;

Базируются на метриках Холстеда или на статистических деревьях исполнения.

6. Текстовые редакторы;

7. Синтаксически-ориентированные редакторы

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

EMACS, MENTOR, ALOE

8. Гипертекстовые средства.

9. Системы документирования

Основаны на различных принципах сбора информации по исходным текстам программ.

Java Doc, Toolbook.

10. Системы разработки интерфейсов.

В настоящее время часто входят в CASE-средства.

11. СУБД

    • Реляционные;

    • Логические;

    • Объектные.

Системы управления базами знаний и экспертные системы.

• Системы AI;

• Механизмы вывода на знаниях (логический вывод; метод, реализующий обратный вывод Маркова; продукционный вывод);

• Механизмы неточного вывода на знаниях (присоединенный механизм и специально ориентированный).