Структура целей разрабатываемой программы

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

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

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

Суть нисходящей стратегии в том, что цели разрабатываемого ПП структурируются по схеме: «целиподцели 1-го уровня…подцели i-го уровня…подцели n-уровня» - функции до такой степени детализации, когда реализация подцелей последнего уровня становится очевидной.

Ограничения, учитываемые в программе обработки

1. Проверка на корректность файла F1:

1. Поле «Регистрационный номер» должно быть уникальным;

2. Поле «Регистрационный номер» должно быть целым неотрицательным числом;

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

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

5. Поле «Цена» должно содержать вещественное неотрицательное число.

2. Проверка на корректность файла F2:

1. Поле «Регистрационный номер» должно быть целым неотрицательным числом;

2. Поле «Название отдела» содержит буквы латинского и русского алфавита, цифры, а также символы пунктуации;

3. Поле «Материально ответственное лицо» содержит буквы латинского и русского алфавита, а также символы пунктуации;

4. Записи таблицы F2 должны содержать все значения регистрационных номеров соответствующих записям таблицыF1.

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

Схема данных

Схема работы программы

Схема работы основной части

Схема подпрограммы «Чтение и проверка на корректность файла F1»

Схема подпрограммы «Чтение и проверка на корректность файла F2»

Схема подпрограммы «Чтение полей структуры PriceItem»

Схема подпрограммы «Чтение полей структуры Department»

Схема подпрограммы «Создание записей таблицыF3»

Схема подпрограммы «Формирование выходного файлаF3»

Внешние спецификации функций разрабатываемой программы.

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

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

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

Функция «чтение и проверка на корректность файла F2» должна выявить ситуации, когда название отдела и фамилия материально-ответственного лица содержат неразрешенные символы, или регистрационные номера являются отрицательными числами.

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

Это словесное описание выполняемой функции формализуется в виде таблиц решений.