4. Предположение об ошибке.

Делаются интуитивные предположения вероятных ошибок.

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

Контроль ошибок ввода сюда же стоит отнести

Три класса условий проверки программных изделий:

1. Проверка в нормальных условиях. (нормальный ход вещей; условия посреди класса)

2. Проверка в экстремальных условиях:

а. граничные условия. (очень большие числа, очень малые числа)

б. граничные объемы данных (слишком большое/мал. количество записей, если не поступает ни одного элемента данных, или только один).

в. Пустые значения (нули для чисел, пробелы для символов).

III. Проверка в исключительных условиях (ввод данных, значения которых за пределами допустимой области (выход индексов за допустимые пределы, деление на «0») .

Стратегия построения тестов.

1. Сначала используют ФТ (связывают входы с выходами)

2. Используют эквивалентное разбиение.

3. Применяют анализ граничных условий.

4. предположение об ошибках.

Если необходимо, то используют СТ.

Парадигмы, разработка ИС (образцы, модели).

В практике разработки ИС сформировались различные подходы к их созданию. Старейшая и широко используемая модель – это ЖЦ. По сути это «каскадная» модель. Можно назвать ЖЦ «естественным» подходом к созданию ИС. Однако на практике редко следуют этой модели в чистом виде как линейной последовательности этапов. Почему редко?

Во-первых, в процессе разработки всегда появляются итерации, обратные связи.

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

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

1. ЖЦ «каскад»

2. Прототип

3. Спиральная модель

4. Техника 4-го поколения

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

2. Прототип

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

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

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

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

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

Как и во всех случаях разработки ИС данная модель так же начинается со сбора требований. Разработчик и заказчик определяют общие цели продукта, идентифицируют наиболее известные требования, затем появляется «Быстрый проект». Он концентрирует внимание на тех аспектах системы, которые видимы для пользователя. Например, выходные данные, выходные форматы. «Быстрый проект» ведет к конструированию прототипа. Прототип оценивается пользователем и используется для уточнения требований к разрабатываемой системе. Процесс настройки прототипа на потребности пользователя итерационный. Постепенно он дает все лучшее понимание разработчикам потребности заказчика.

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

3. Спиральная модель.

Она включает все лучшие черты классического ЖЦ и прототипа, но в нее добавлен новый элемент – анализ риска. В модели определены 4 основных вида деятельности:

1. планирование – определение целей, ограничений, альтернатив;

2. анализ риска – это анализ альтернатив, определение и разрешение рисков;

3. инженерия – изготовление продукта очередного уровня;

4. оценка заказчика – экспертиза результатов инженерной деятельности.

Эти виды деятельности размещаются каждый в своем квадранте следующей модели.

Каждый виток модели соответствует фрагменту или версии будущего изделия. На каждой итерации (на каждом витке) производится следующее:

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

Главное при спиральной модели – не надо сразу полно и точно формулировать требования к системе.

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

Диаграммы потоков данных (ДПД)

Сущность ДПД

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

Компоненты ДПД.

Они строятся на базе 4-х компонент:

1. поток данных

2. процесс

3. хранилище (накопитель данных)

4. внешняя сущность (терминатор)

Существует 2 нотации для ДПД (системы изображения)

Одна ранее введенная: Де Марко, Йордан

Вторая: Гейн, Сарсон

Мы будем ориентироваться на усовершенствованный вариант: Гейн, Сарсон.

Уровни ДПД

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

Система распределения заказов.

Рисунок ???

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

Еще большая детализация представлена на следующей схеме.

Рисунок ???

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

Существует такой прием как НАСЛОЕНИЕ.

Парадигмы разработки ИС

4 Техника 4-го поколения

4^th Generation Technique

4 GT охватывает широкий круг программных средств, которые имеют одну общую черту:

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

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

1. непроцедурный язык для запросов к БД

2. генератор отчетов

3. генератор кода

4. средства манипуляции данными

5. графика высокого уровня

6. электронная таблица

и др.

Пока не создано интегрированной среды 4 GT, которая могла бы быть применена для всех категорий ПО.

Парадигму 4 GT можно представить следующим образом:

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

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

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