Технология разработки программного обеспечения

Таблица 2 Этапы и сроки выполнения курсовой работы Этапы выполнения Сроки Технический проект 15-17 недели II семестра Утверждение технического задания и 4 неделя III семестра программы и методики испытаний Приемка программного обеспечения 12-14 недели III семестра Защита курсовой работы 15-17 недели III семестра 2.ТЕХНИЧЕСКИЙ ПРОЕКТ Согласно ГОСТ 19.102-77 'Стадии разработки' технический проект предполагает выполнение следующих работ: уточнение струтуры входных и выходных данных; разработку алгоритма решения задачи; определение формы представления входных и выходных данных; определение семантики и синтаксиса языка; разработку структуры программы; окончательное определение конфигурации технических средств. В связи с этим, технический проект должен быть разработан в форме иерархического набора формальных спецификаций, описывающих процедуры, данные и итерации в соответствии с шаблонами, описанными в [1]. 3.ОБЩИЕ ТРЕБОВАНИЯ Разрабатываемое ПО должно работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипулятора типа 'мышь'. Рекомендации по разработке графического пользовательского интерфейса приведены в [1]. Программная документация, входящая в состав курсовой работы, должна соответствовать требованиям Единой системы программной документации (ЕСПД) [2]. В [1] приводятся выдержки из основных стандартов ЕСПД. ПРИЛОЖЕНИЕ 1 ГЕОМЕТРИЧЕСКИЙ РЕДАКТОР ПЛОСКИХ ДЕТАЛЕЙ Постановка задачи Проектирование изготовления деталей из листовых материалов всегда начинается с получения их разверток или выкроек, которые могут быть представлены двумерной абстракцией, вполне пригодной для решения многих технологических задач. В связи с этим, необходимость разработки геометрического редактора, позволяющего формировать двумерные детали, является достаточно актуальной.

Проектируемые при этом детали должны описываться своими наружным и внутренними контурами. Будем полагать, что все контуры деталей являются многоугольниками, что позволяет определить объекты детали в форме Бэкуса-Наура следующим образом: ..................:= .........:= := контур> внутренних контуров> ..................:= .................:= := ...................:= .........:= ............:= в котором любые два соседних в последовательности ребра имеют общую граничную точку> ..:= := К основным функциям редактирования можно отнести следующие [3]: - перенос объекта изображения в другое место. Это действие связано с выполнением поступательного движения; - копирование объекта изображения в другом месте.

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

Выполняется относительно заданной плоскости; - уничтожение объекта изображения. Эта функция вызывает удаление выбранного объекта изображения с экрана; - изменение масштаба.

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

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

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

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

Декартовы координаты точки (x,y) на плоскости заменятся ее однородными координатами (x,y,1). Геометрическое преобразование, примененное к объекту или совокупности объектов, может быть конкатенацией (последовательностью) нескольких преобразований. Для его описания используется матрица, представляющая собой произведение матриц более простых преобразований (что является следствием ассоциативности матричного умножения). К основным (элементарным) преобразованиям на плоскости относятся следующие [4]: - преобразование переноса на вектор Т (tx,ty); - преобразование поворота относительно начала координат на угол al; - преобразование масштаба на вектор Е (ex,ey), - преобразования зеркальной симметрии относительно координатных осей.

Матрицы основных двумерных геометрических преобразований 1 0 0 cos(al) sin(al) 0 M(T) = 0 1 0 M(R(al)) = -sin(al) cos(al) 0 tx ty 1 0 0 1 ex 0 0 -1 0 0 1 0 0 M(E) = 0 ey 0 M(S(x)) = 0 1 0 M(S(y)) = 0 -1 0 0 0 1 0 0 1 0 0 1 Преобразование вектора P(x,y,1) в вектор P'(x',y',1) производится умножением вектора-строки на матрицу M соответсвующего преобразования a b c P' = P*M = x y 1 * d e f = (ax+dy+g) (bx+ey+h) (cx+fy+i) , g h i где выражения (ax+dy+g) и (bx+ey+h) соответствуют компонентам x' и y'вектора P'. Рассмотрим получение матрицы сложного преобразования, осуществляющего поворот на угол al относительно произвольной точки A (xa,ya). Матрица этого преобразования может быть получено с помощью последовательности элементарных преобразований: - перенос на вектор (-xa,-ya) для совмещения центра вращения с началом координат; - поворот на угол al относительно начала координат; - обратный перенос на вектор (xa,ya). Суммарная матрица преобразования в данном случае будет получена из выражения 1 0 0 cos(al) sin(al) 0 1 0 0 M = 0 1 0 * -sin(al) cos(al) 0 * 0 1 0 -xa -ya 1 0 0 1 xa ya 1 Программа должна поддерживать локальную базу данных, в которой, по желанию пользователя, может сохраняться информация о спроектированных деталях.

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

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

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

Техническое задание ВВЕДЕНИЕ Наименование - геометрический редактор плоских деталей (далее просто редактор). Краткая характеристика - двумерный геометрический редактор с локальной базой сформированных контуров. 1.ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ Задание преподавателя для проведения лабораторных занятий и выполнения курсовой работы. 2.НАЗНАЧЕНИЕ РАЗРАБОТКИ Редактор предназначен для формирования и редактирования плоских деталей, ограниченных многоугольниками, а также для их хранения в базе данных. 3.ТРЕБОВАНИЯ К ПРОГРАММЕ 3.1.Требования к функциональным характеристикам 3.1.1.Редактор должен работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипулятора типа 'мышь'. 3.1.2.Пользователь, по своему желанию, должен иметь возможность установки масштабного поля для каждого окна. 3.1.3.В одном окне возможна работа с несколькими деталями. 3.1.4.Программа должна обеспечивать следующие функции редактирования: указание, формирование, фиксация, отмена фиксации, копирование, удаление, перемещение, вращение точек, ребер, сегментов, контуров, деталей. Все указанные функции, кроме копирования, должны работать в пределах активного окна.

Функция копирования должна осуществляться также и в межоконном режиме. При наличии нескольких деталей в окне редактор не должен допускать взаимных наложений. 3.1.5.Редактор должен обеспечивать расчет следующих характеристик: - для точки: - координаты в принятом масштабном поле; - для ребра: - длина; - угол наклона; - для детали (контура): - периметр; - площадь; - положение центра масс; - положение центра давления; - момент инерции относительно произвольной точки. 3.1.6.Информация о сформированной детали может быть сохранена в локальной базе данных редактора. 3.1.7.Должен быть обеспечен графический просмотр базы данных с возможностью удаления из нее или копирования в активное окно указанной детали. 3.1.8.Информация о сформированной детали может быть сохранена в форме выходного файла следующей структуры: ... ... 3.1.9.Редактор должен уметь считывать геометрическую информацию из файла описанной структуры. ... ... 3.1.10.Редактор должен позволять размещение деталей в прямоугольной области и вывод получаемого размещения в файл геометрической информации, первой деталью которого будет прямоугольник области размещения. 3.2.Требования к надежности 3.2.1.Программа должна обрабатывать ошибочные действия пользователя и сообщать ему об этом. 3.2.2.Программа должна обеспечивать контроль входной и выходной информации в форме файлов геометрической информации. . . . 3.4.Требования к составу и параметрам технических средств 3.4.1.Программное обеспечение разрабатывается для персональной вычислительной техники типа не ниже IBM PC-386 со следующими характеристиками: - объем ОЗУ не ниже 1 Mb; - графический адаптер SVGA; - манипулятор типа 'мышь'. 3.4.2.ЭВМ должна работать под управлением операционной системы не ниже чем MS-DOS 5.0. 3.5.Требования к информационной и программной совместимости 3.5.1.Требование информационной совместимости должно быть обеспечено работой с файлами геометрической информации определенной структуры в качестве входной и выходной информации. ПРИЛОЖЕНИЕ 2 СИСТЕМА ТРИАНГУЛЯЦИИ МНОГОУГОЛЬНЫХ ОБЛАСТЕЙ Постановка задачи Метод конечных элементов (МКЭ) широко применяется для решения различных задач, математическая модель которых представляется дифференциальными уравнениями в частных производных.

Первый этап решения задачи этим методом состоит в дискретизации рассматриваемой области на треугольники, четырехугольники, трехгранные пирамиды ит.д. Такое разбиение несет геометрическую информацию о покрытии области элементами, с каждым из которых связано определенное количество численных значений, необходимых для последующих вычислений в МКЭ (построение матриц, блокирование некоторых степеней свободы, решение систем уравнений, визуализация и т.д.). Эту информацию удобно определить как структуру данных, содержащую в сжатой и доступной форме все величины (геометрические и числовые). Многочисленные методы построения разбиений областей с геометрической точки зрения подразделяются на три основных класса [4,5]: - построение разбиения, осуществляемого подходящим преобразованием отображения разбиения области с геометрически простой формой; - построение разбиения, осуществляемого подходящим преобразованием уже существующего разбиения; - прямое, элемент за элементом, построение разбиения, начиная с задания распределения точек в области или на границе.

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

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

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

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

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

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

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

Техническое задание ВВЕДЕНИЕ Наименование - система трангуляции многоугольных областей (далее просто триангулятор). Краткая характеристика - двумерный триангулятор с локальной базой сформированных сеток деталей. 1.ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ Задание преподавателя для проведения лабораторных занятий и выполнения курсовой работы. 2.НАЗНАЧЕНИЕ РАЗРАБОТКИ Триангулятор предназначен для формирования и редактирования треугольной сетки, заполняющей заданный многоугольник, а также для хранения полученных сетей в базе данных. 3.ТРЕБОВАНИЯ К ПРОГРАММЕ 3.1.Требования к функциональным характеристикам 3.1.1.Редактор должен работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипулятора типа 'мышь'. 3.1.2.Пользователь, по своему желанию, должен иметь возможность установки масштабного поля для каждого окна. 3.1.3.Программа должна обеспечивать разбиение многоугольной области на треугольники, количество которых может устанавливать пользователь. 3.1.4.Программа должна включать, по желанию пользователя, минимизацию разности номеров вершин треугольников. 3.1.5.Информация о сформированной сети треугольников может быть сохранена в локальной базе данных триангулятора. 3.1.6.Должен быть обеспечен графический просмотр базы данных с возможностью удаления из нее или копирования в активное окно указанного разбиения. 3.1.7.Информация о сформированном разбиении может быть сохранена в форме выходного файла геометрической информации следующей структуры: ... ... 3.1.8.Триангулятор может использовать в качестве входной информации файл геометрической информации о детали или об уже имеющемся разбиении. 3.1.9.Программа должна обеспечивать возможность просмотра выхоного файла. 3.2.Требования к надежности 3.2.1.Программа должна обрабатывать ошибочные действия пользователя и сообщать ему об этом. 3.2.2.Программа должна обеспечивать контроль входной и выходной информации в форме файлов геометрической информации. . . . 3.4.Требования к составу и параметрам технических средств 3.4.1.Программное обеспечение разрабатывается для персональной вычислительной техники типа не ниже IBM PC-386 со следующими характеристиками: - объем ОЗУ не ниже 1 Mb; - графический адаптер SVGA; - манипулятор типа 'мышь'. 3.4.2.ЭВМ должна работать под управлением операционной системы не ниже чем MS-DOS 5.0. 3.5.Требования к информационной и программной совместимости 3.5.1.Требование информационной совместимости должно быть обеспечено работой с файлами геометрической информации определенной структуры в качестве входной и выходной информации. ПРИЛОЖЕНИЕ 3 СИСТЕМА МИНИМИЗАЦИИ ПУТИ РЕЖУЩЕГО ИНСТРУМЕНТА ПРИ РАСКРОЕ Постановка задачи Получение заготовок во многих отраслях, таких как судостроение, авиастроение6 легкая промышленность, автомобилестроение и др., основано на вырезке необходимых контуров из листового материала с помощью термических устройств.

Минимизация пути режущего инструмента обеспечивает существенную экономию энергии и трудозатрат.

Рассмотрим исходную постановку задачи.

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

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

Очевидно,минимальным будет путь, когда режущее устройство пройдет через каждое ребро любого контура только один раз. Если точки касания контуров деталей рассматривать как вершины плоского графа, то сформулированная задача минимизации пути является задачей опреления цикла Эйлера для этого графа [6]. Входная информация для системы будет представляться в форме файла геометрической информации (Приложение 4). Первой деталью в этом файле будет прямоугольник области размещения.

Детали, размещенные в этой области, будут представлены в произвольном порядке.

Найденный путь режущего устройства может быть показан на экране и выведен в форме файла геометрической информации.

Перечисление вершин треугольников в соответствующем дескрипторе этого файла должно соответствовать найденному пути.

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

Техническое задание ВВЕДЕНИЕ Наименование - система минимизации пути режущего инструмента при раскрое листовых материалов (далее просто минимизатор). Краткая характеристика - двумерный минимизатортор с локальной базой сформированных маршрутов резки. 1.ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ Задание преподавателя для проведения лабораторных занятий и выполнения курсовой работы. 2.НАЗНАЧЕНИЕ РАЗРАБОТКИ Минимизатор предназначен для формирования минимального пути вырезки многоугольных контуров, размещенных в прямоугольной области, а также для хранения полученных маршрутов в базе данных. 3.ТРЕБОВАНИЯ К ПРОГРАММЕ 3.1.Требования к функциональным характеристикам 3.1.1.Редактор должен работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипулятора типа 'мышь'. 3.1.2.Пользователь, по своему желанию, должен иметь возможность установки масштабного поля для каждого окна. 3.1.3.Минимизатор должен обеспечивать нахождение минимального пути с проходом только один раз через каждое ребро каждого многоугольного контура детали в области размещения. 3.1.4.Найденный путь должен демонстрироваться на экране в различных режимах. 3.1.5.Информация о размещении контуров и сформированном маршруте может быть сохранена в локальной базе данных минимизатора. 3.1.6.Должен быть обеспечен графический просмотр базы данных с возможностью удаления из нее или копирования в активное окно указанного размещения с имеющимся маршрутом. 3.1.7.Информация о размещении и сформированном маршруте может быть выведена в форме файла геометрической информации следующей структуры: ... ... 3.1.8.Перечисление вершин контуров деталей в соответствующем дескрипторе выходного файла должно соответствовать сформированному маршруту резки. 3.1.9.Программа должна использовать в качестве входной информации файл геометрической информации, первой деталью которого будет прямоугольник области размещения. 3.1.10.Программа должна обеспечивать просмотр выходного файла. 3.2.Требования к надежности 3.2.1.Программа должна обрабатывать ошибочные действия пользователя и сообщать ему об этом. 3.2.2.Программа должна обеспечивать контроль входной и выходной информации в форме файлов геометрической информации. . . . 3.4.Требования к составу и параметрам технических средств 3.4.1.Программное обеспечение разрабатывается для персональной вычислительной техники типа не ниже IBM PC-386 со следующими характеристиками: - объем ОЗУ не ниже 1 Mb; - графический адаптер SVGA; - манипулятор типа 'мышь'. 3.4.2.ЭВМ должна работать под управлением операционной системы не ниже чем MS-DOS 5.0. 3.5.Требования к информационной и программной совместимости 3.5.1.Требование информационной совместимости должно быть обеспечено работой с файлами геометрической информации определенной структуры в качестве входной и выходной информации. ПРИЛОЖЕНИЕ 4 СТРУКТУРА ДАННЫХ ФАЙЛА ГЕОМЕТРИЧЕСКОЙ ИНФОРМАЦИИ Файл должен иметь следующую структуру (см.рис): - информационная часть; - дескриптор деталей; - дескриптор контуров; - дескриптор ребер; - дескриптор вершин; Информационная часть должна содержать следующую информацию: - количество деталей в соответствующем дескрипторе; - количество контуров в соответствующем дескрипторе; - количество ребер в соответствующем дескрипторе; - количество вершин в соответствующем дескрипторе.

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

Каждая вершина должна быть представлена в своем дескрипторе двумя координатами (x,y). Структура файла геометрической информации Количество деталей ИНФОРМАЦИОННАЯ ЧАСТЬ Количество контуров Количество ребер Количество вершин Кол-во Списки ДЕСКРИПТОР ДЕТАЛЕЙ контуров контуров ДЕСКРИПТОР КОНТУРОВ кол-во Списки ребер ребер Начало Конец ДЕСКРИПТОР РЕБЕР ДЕСКРИПТОР ВЕРШИН X Y ПРИЛОЖЕНИЕ 5 ИНТЕРАКТИВНЫЙ КОРРЕКТИРОВЩИК ПРАВОПИСАНИЯ Постановка задачи Корректировщик правописания представляет собой программу, которая получает в качестве входных данных словарь и текстовый файл и исправляет затем в текстовом файле ошибки правописания.

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

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

Результатом работы корректировщика является исправленный текст и, возможно, обновленный словарь.

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

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

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

Словарь представляет собой ASCII файл, слова в котором представлены в буквах нижнего регистра и разделены пробелами, символами табуляции и перевода строки. Слова в словаре неупорядоченны. Этот набор требований к программе является неполным. Для словаря может понадобиться дополнительная информация. Вы должны также принять решение о возможностях, предоставляемых программой, и так же подробно проанализировать обработку входных символов. Можно вывести ряд предположений: 1.Символьная обработка. Вы должны определить то, каким образом программа обращается с символами пунктуации, например с кавычками, со словами или акронимами, включающими цифры, дефисами, стандартными сокращениями ('и т.д.') и так далее.

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

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

Необходимо, чтобы программой можно было легко пользоваться. На этот счет имеются следующие соображения: а) возложите на пользователя указание имен для исходного и результирующего файлов - как для текста, так и для словаря; б) дайте возможность пользователю исправить несколько текстовых файлов без выхода из программы корректировщика; в) запрашивайте у пользователя ввод возможных правильных ответов при отображении неверно заданного слова; г) реализуйте команду help ('вспомогательная информация'), описывающую эффект каждого из вышеописанных ответов подробно. ПРИЛОЖЕНИЕ 6 ИНТЕРАКТИВНЫЙ ФОРМАТИРОВЩИК ТЕКСТА Постановка задачи Входные данные для форматировщика текста состоят из последовательности вводимых с клавиатуры неформатированных строк текста.

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

Пользователь должен иметь возможность переустановки этих значений.

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

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

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

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

Форматирование должно осуществляться от текущей позиции курсора до границы абзаца. Л И Т Е Р А Т У Р А 1.Курсовое проектирование.

Методические указания для студентов специальности 220400. Электронная версия. 2.Единая система программной документации.- М.: Изд-во стандартов, 1985.- 128 с. 3.Гардан И., Люка М. Машинная графика и автоматизация конструирования.- М.: Мир, 1987.- 272 с. 4.Математика и САПР: В 2-х кн. Кн.1.- М.: Мир, 1988.- 204 с. Кн.2.М.: Мир, 1989.- 264 с. 5.Шикин Е.В., Боресков А.В., Зайцев А.А. Начала компьютерной графики.М.: ДИАЛОГ-МИФИ, 1993.- 138 с. 6.Липский В. Комбинаторика для программистов.- М.: Мир, 1988.- 213 с. С О Д Е Р Ж А Н И Е В В Е Д Е Н И Е................................................. 3 1.Содержание и этапы выполнения................................. 4 2.Технический проект............................................ 4 3.Общие требования.............................................. 4 Приложение 1. Геометрический редактор плоских деталей........... 5 Приложение 2. Система триангуляции многоугольных областей....... 9 Приложение 3. Система минимизации пути режущего инструмента при раскрое...........................................11 Приложение 4. Структура данных файла геометрической информации..13 Приложение 5. Интерактивный корректировщик текста...............15 Приложение 6. Интерактивный форматировщик текста................16 Литература......................................................17 Т Е Х Н О Л О Г И Я П Р О Г Р А М М И Р О В А Н И Я Методические указания к курсовой работе Составили: Клеванский Николай Николаевич Алексеева Елена Юрьевна Рецензент: Лалетин Сергей Сергеевич Редактор 1.ИСПОЛЬЗОВАНИЕ АБСТРАКЦИЙ И СПЕЦИФИКАЦИЙ В РАЗРАБОТКЕ ПО 1.1.Абстракции программы Любые достаточно большие программы составляются путем декомпозиции задачи. Эта декомпозиция основана на опознавании абстракций.

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

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

Задачи абстрагирования и последующей декомпозиции типичны для процесса создания программ: декомпозиция используется для разбиения программы на компоненты, которые могут быть затем объединены, позволив решить основную задачу; абстрагирование же предполагает продуманный выбор компонент. В общем случае, любую программу можно представить набором следующих процедурных абстракций.

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

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

Управляющая информация Входная Выходная Процедура информация информация Рис.1.2.Абстракция процедуры Рассматривая программу не как набор процедур, а прежде всего как некоторые наборы данных, каждый из которых имеет разрешенную группу процедур, получаем следующее абстрактное представление программы. Ввод информации Исходная Преобразование Выходная информация информации информация Преобразованная Вывод информация информации Рис.1.3.Абстракция программы как набора данных, обрабатываемых процедурами.

Анализ рис.1.3 позволяет также получить абстракцию данных.

Процедуры управления Процедуры Процедуры Данные ввода вывода Процедуры преобразования Рис.1.4.Абстракция данных.

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

Условно эти методы можно разделить на формульные и графические.

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

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

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

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

Использование абстракции через параметризацию обобщает процедуру сортировки и делает ее более универсальной.

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

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

Дальнейшее абстрагирование позволяет добиться большего обобщения процедуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фактические данные связываются с этими параметрами в момент использования такой абстракции.

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

Главное преимущество абстракции через спецификацию заключается в несущественности способа реализации.

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

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

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

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

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

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

Семантическая часть спецификации состоит из трех предложений - requires (требует), modifies (модифицирует) и effects (делает). Эти предложения должны появляться в указанном ниже порядке, однако предложения requires и modifies обязательными не являются. pname = proc(входные данные) returns (выходные данные) requires - этот оператор задает необходимые требования modifies - этот оператор идентифицирует все модифицируемые входные данные effects - этот оператор описывает выполняемые функции Рис.1.5.Шаблон спецификации для процедурных абстракций.

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

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

Оператор modifies задает список имен входных параметров, модифицируемых процедурой. Если входные параметры не указаны, то это предложение может быть опущено.

Предложение effects описывает работу процедуры со значениями, не охваченными предложением requires. Оно определяет выходные значения и модификации, производимые над входными параметрами, перечисленными в в списке modifies. Предложение effects составляется исходя из предположения, что требования предложения requires удовлетворены.

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

Процедуры sort и search не изменяют входные данные, а процедура clear - изменяет, что отмечено в предложении modifies ее спецификации.

Процедуры sort и clear являются общими процедурами, поскольку их спецификации не содержат предложений requires. Процедура search является частичной; она выполняет свои функции только в том случае, если входной массив отсортирован.

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

Приведенная на рис.1.6 спецификация процедуры sort предназначена для работы с массивом целых чисел. Эта процедура была бы более полезной, если бы могла работать с массивами любых типов данных - действительных чисел, символьных, строковых, вплоть до вводимых пользователем. Для обеспечения подобного обобщения используется абстракция через параметризацию, при которой типы данных являются параметрами. sort = proc(a:array of int) returns (b:array of int) effects - возвращает новый массив той же размерности, что и a, содержащий элементы из массива a, упоря доченные по возрастанию clear = proc(a:array of int) modifies - a effects - удаляет из массива a все повторяющиеся элементы search= proc(a:array of int;x:int) returns (i:int) requires - массив a упорядочен по возрастанию effects - если элемент x принадлежит массиву a, то возвращается значение i, такое, что a[i]=x; в противном случае - значение i на единицу большее верхней границы массива a Рис.1.6.Спецификации процедурных абстракций. При использовании типов в качестве параметров некоторые значения параметров могут не иметь смысла.

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

Ограничения на параметры типа предполагают набор некоторых заданных операций над ними.

Спецификация абстракции должна содержать эти ограничения в предложении requires. Некоторые спецификации для параметризованных процедур показаны на рис.1.7. Эти спецификации отличаются от спецификаций непараметризованsort = proc[t:type](a:array [t]) returns (array [t]) requires - t имеет операцию lt:proctype(t,t) returns(bool), которая упорядочивает t modifies - a effects - возвращает новый массив той же размерности, что и a, содержащий элементы из массива a, упоря доченные по возрастанию search= proc[t:type](a:array [t];x:t) returns (int) requires - t имеет операции equal,lt:proctype(t,t) returns (bool), такие, что t упорядочивается через equal, а массив a упорядочен по возрастанию через lt effects - если элемент x принадлежит массиву a, то возвращается значение i, такое, что a[i]=x; в противном случае - значение i на единицу большее верхней границы массива a Рис.1.7.Спецификации параметризованных процедур. ных процедур только заголовком, который содержит дополнительную часть, содержащую параметры.

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

Например, абстракция sort требует, чтобы параметр t имел операцию lt, упорядочивающую t. Аналогично процедура search требует, чтобы ее параметр поддерживал как операцию lt, так и операцию equal. (lt - меньше, equal - равно). Параметризованная абстракция в действительности представляет собой класс взаимосвязанных абстракций, определенных в одной спецификации.

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

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

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

Абстракции через спецификацию достигаются за счет представления операций как части типа. Если рассматривать тип данных просто как набор объектов, то все, что необходимо сделать для реализации типа, - это выбрать представление памяти для объектов. Тогда все программы могут быть реализованы в терминах этого представления. В случае изменения представления программы, использующие этот тип, также должны быть изменены. При включении операций в тип данных единственным требованием будет следующее: пользователи (программы) употребляют непосредственно эти операции, не обращаясь к представлению.

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

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

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

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

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

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

Вместо этого должна иметься определяющая его спецификация. Так как объекты типа используются только вызовом операций, основная часть спецификации посвящена описанию того, что эти операции делают. Общий вид спецификации данных состоит из заголовка, определяющего имя типа и имена его операций, и двух главных секций - секции описания и секции операций. dname = data type is список операций Описание Здесь приводится описание абстракции данных Операции Здесь задаются спецификации для всех операций end dname Рис.1.8.Общий вид спецификации абстракции данных. В секции описания тип описывается как целое.

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

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

Рассмотрим спецификацию абстракции данных intset. Наборы целых чисел intset - это неограниченные множества целых чисел с операциями создания нового, пустого набора, проверки данного целого числа на принадлежность данному набору intset и добавления или удаления элементов. intset = data type is create, insert, delete, member, size, choose Описание Наборы целых чисел intset - это неограниченные математические множества целых чисел.

Наборы целых чисел изменяемые: операции insert и delete добавляют и удаляют целые числа из набора.

Операции create = proc () returns (intset) effects возвращает новый, пустой набор intset insert = proc (s: intset, x:int) modifies s effects добавляет x к элементам s; после добавления - возврат delete = proc (s: intset, x:int) modifies s effects удаляет x из s member = proc (s:intset, x:int) returns (bool) effects возвращает значение true, если x принадлежит s size = proc (s: intset) returns (int) effects возвращает число элементов в s choose = proc (s: intset) returns (int) requires набор s не пуст effects возвращает произвольный элемент s end intset Рис.1.9.Спецификация типа данных intset. На рис.1.10 представлена спецификация типа данных poly. Полиномы poly - это неизменяемые полиномы с целыми коэффициентами.

Предоставляются операции для создания одночленного полинома, для сложения, вычитания и умножения полиномов, а также для проверки двух полиномов на равенство. poly = data type is create,degree,coef,add,mul,sub,minus,equal Описание Полиномы poly - это неизменяемые полиномы с целыми коэффициентами Операции create = proc (c,n:int) returns (poly) requires n>=0 n effects возвращает полином cx. Например , poly.create(0,0) = 0 poly.create(3,0) = 3 3 poly.create(6,3) = 6x degree = proc (p: poly) returns(int) effects возвращает степень p, т.е. наибольшую степень при ненулевом коэффициенте.

Степень нулевого полинома равна 0. Например, 2 poly.degree(17) = 0 poly.degree(x +1) = 2 coef = proc (p: poly, n:int) returns (int) requires n>=0 effects возвращает коэффициент члена p со степенью n. Возвращает 0, если n больше степени p. Например, 3 poly.coef(x +2x+1,4) = 0 3 poly.coef(x +2x+1,1) = 2 add = proc (p,q: poly) returns (poly) effects возвращает полином, являющийся суммой полиномов p и q mul = proc (p,q: poly) returns (poly) effects возвращает полином, являющийся произведением полиномов p и q sub = proc (p,q: poly) returns (poly) effects возвращает полином, являющийся разностью полиномов p и q minus = proc (p: poly) returns (poly) effects возвращает полином, являющийся разностью полиномов z и p, где z - нулевой полином equal = proc (p,q: poly) returns (bool) effects возвращает значение true, если p и q имеют одинако вые коэффициенты при соответствующих членах, и зна чение false - в противном случае end poly Рис.1.10.Спецификация абстракции данных для полиномов. Типы - выгодные параметры для данных, как и для процедур.

Например, рассмотрим абстракцию общего набора set, в котором элементы набора могут быть произвольного типа.

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

Следовательно, спецификация set, представленная на рис.1.11, требует, чтобы элементы типа имели операцию equal. Эти требования помещены сразу после заголовка. set = data type [t:type] is create, insert, delete, member, size, choose Requires t имеет операцию equal:proctype(t,t) returns(bool), то есть условие проверки равенства t Описание Общие наборы set - это неограниченные математические наборы Эти наборы изменяемые: операции insert и delete добавляют и уничтожают элементы набора Операции create = proc () returns (set [t]) effects возвращает новый, пустой набор set insert = proc (s: set[t], x:t) modifies s effects добавляет x к элементам s; после добавления - возврат delete = proc (s: set[t], x:t) modifies s effects удаляет x из s member = proc (s: set[t], x:t) returns (bool) effects возвращает значение true, если x принадлежит s size = proc (s: set[t]) returns (int) effects возвращает число элементов в s choose = proc (s: set[t]) returns (t) requires набор s не пуст effects возвращает произвольный элемент s end set Рис.1.11.Спецификация параметризованной абстракции данных. В качестве параметра для набора set может быть использован тип poly. Например , pset = set[poly]. Poly является законным параметром для абстракции данных set, так как имеет операцию equal. В следующем примере параметризованного типа данных, описывающих списки, требования налагаются на индивидуальные операции, а не на тип как целое.

Неограниченные списки содержат элементы некоторого произвольного типа. Для них имеются операции создания пустого списка, формирования нового списка, состоящего из данного элемента и элементов уже существующего списка, и декомпозиции списка на первый элемент и остальные элементы. list = data type [t:type] is create,cons,first,rest,empty,equal Описание Списки - это неизменяемые неограниченные последовательности элементов типа t Операции create = proc () returns (list [t]) effects возвращает новый, пустой список cons = proc (x: list[t], i:t) returns(list[t]) effects возвращает список, у которого первый элемент i, а остальные элементы - элементы x first = proc (x: list[t]) returns(t) requires x - не пуст effects возвращает первый элемент x rest = proc (x: list[t]) returns (list[t]) requires x - не пуст effects возвращает список, содержащий все элементы x, кроме первого empty = proc (x: list[t]) returns (bool) effects возвращает значение true, если x - пуст, и значение false - в противном случае equal = proc (x,y: list[t]) returns (bool) requires t имеет операцию equl:proctype(t,t) returns(bool), то есть условие равенства t effects возвращает значение true, если x и y содержат одинаковые (в соответствии с t.equal) и одинаково рас положенные элементы end list Рис.1.12.Спецификация параметризованной абстракции данных для списков.

Следует заметить, что списки как целое не налагают никаких требований на тип параметра. Таким образом, list[intset] - законный тип.

Однако операция equal должна проверять элементы на равенство, поэтому она в предложении requires налагает на t требования.

Следовательно, list[intset] имеет все операции списков, кроме операции equal, так как intset не имеет операции equal. В качестве последнего примера рассмотрим упорядоченные списки, в которых элементы отсортированы по доступу.

Упорядоченные списки - изменяемы и параметризуемы по типу, который должен быть полностью упорядочен его операциями lt и equal. То есть, упорядоченные списки не содержат дублирующих друг друга элементов. olist = data type [t:type] is create,addel,remel,is_in,empty,least Requires - t имеет операции equal,lt:proctype(t,t) returns (bool), которые определяют упорядочение t Описание Упорядоченные списки olist - изменяемые списки элементов.

Операции addel и remel модифицируют списки.

Каждый элемент упорядоченного списка отличается от остальных (как определяется t.equal). Операция least возвращает наименьший элемент olist (как определяется t.lt) Операции create = proc () returns (olist [t]) effects возвращает новый, пустой список addel = proc (s: olist[t], x:t) requires x не содержится в s; т.е. обращение к is_in(s,x) возвращает false modifies s effects вставляет x в s remel = proc (s: olist[t], x:t) requires x содержится в s; т.е. обращение к is_in(s,x) возвращает true modifies s effects удаляет x из s is_in = proc (s: olist[t], x:t) returns (bool) effects возвращает значение true, если s содержит элемент равный x (используется t.equal), в противном случае возвращает значение false empty = proc (s: olist[t]) returns (bool) effects возвращает значение true, если s не содержит элементов, и значение false - в противном случае least = proc (s: olist[t]) returns(t) requires список не пуст, то есть обращение к операции empty(s) возвращает значение false effects возвращает элемент e из s, такой, что в s не существует элемента, меньшего e(как определяется t.lt) end olist Рис.1.13.Спецификация параметризованной абстракции данных для упорядоченных списков.

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

Неизменяемый тип более надежен, чем изменяемый, однако менее эффективен в связи с необходимостью частой очистки памяти (сбор мусора). Операции абстракции данных распадаются на четыре класса. 1)Примитивные конструкторы. Эти операции создают объекты соответствующего им типа, не используя никаких объектов в качестве аргументов. (Операция create для наборов intset). 2)Конструкторы. Эти операции используют в качестве аргументов объекты соответствующего им типа и создают другие объекты такого же типа. (Операции add и mul - конструкторы для полиномов, операции cons и rest - конструкторы для списков). 3)Модификаторы. Эти операции модифицируют объекты соответствующего им типа. (Операции insert и delete - модификаторы для наборов intset). Очевидно, что только изменяемые типы могут иметь модификаторы. 4)Наблюдатели. Эти операции используют в качестве аргументов объекты соответствующего им типа и возвращают результат другого типа. Они используются для получения информации об объектах. (Операции size, member и choose для наборов intset, операции coef, degree и equal для полиномов). Обычно примитивные конструкторы создают не все, а только некоторые объекты.

Например, операция poly.create создает только одночленные полиномы, а операция intset.create создает только пустой набор.

Другие объекты создаются конструкторами или модификаторами.

Например, операция poly.add может быть использована для получения полиномов, у которых количество членов больше одного, а операция intset.insert - для получения наборов с многими элементами.

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

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

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

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

Например, если для наборов intset будут существовать только операции create, insert и delete, то программы не смогут получить никакой информации относительно элементов набора (так как не имеется наблюдателей). Если к этим трем операциям добавить только одну - size, то уже возможно получение информации об элементах набора (например, можно проверять на принадлежность, удаляя целые числа и анализируя, изменился ли размер). Но тип в этом случае получится неэффективным и неприемлемым. В общем случае абстракция данных должна иметь операции по крайней мере трех из четырех рассмотренных классов. Она должна иметь примитивные конструкторы, наблюдатели и либо конструкторы (если она неизменяемая), либо модификаторы (если изменяемая). Полнота типа зависит от контекста использования, то есть тип должен иметь достаточно богатый выбор операций для его предполагаемого использования. Если тип предполагается использовать в ограниченном контексте, то должно быть обеспечено достаточно операций только для этого контекста. Если тип предназначен для общего использования, желательно иметь богатый набор операций.

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

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

Например, иногда полезно установить свойство, являющееся общим для всех объектов типа. Такое свойство называется инвариантом абстракции. Для доказательства используется метод индукции. Чтобы установить инвариант абстракции необходимо показать, что он сохраняется для всех объектов, произведенных типом. Как правило, используется следующий метод. 1)Показать, что свойство сохраняется для всех объектов, возвращаемых примитивными конструкторами. 2)Показать, что свойство сохраняется для объектов, возвращаемых конструкторами, предполагая, что свойство сохраняется для объектов, передаваемых конструкторам в качестве аргументов. 3)Показать, что при выходе из модификатора свойство сохраняется для модифицированных объектов, предполагая, свойство сохраняется при вызове модификатора.

Например, упорядоченные списки (рис.1.13) не содержат дублирующих элементов. Этот инвариант полезен для определения корректности реализации наборов intset с использованием упорядоченных списков. То, что это свойство является инвариантом, устанавливается следующим образом: 1)оно сохраняется для единственного примитивного конструктора create, так как операция create возвращает новый пустой список; 2)оно сохраняется для операции addel(s,x). При возврате из этой операции в s содержатся те же элементы, которые там были до вызова, плюс элемент x. По предположению, до вызова в s не было дублирующих друг друга элементов. Кроме того, операция addel требует (в предложении requires), чтобы x не содержался в s. Следовательно, набор s с добавленным элементом x не содержит дублирующих друг друга элементов; 3)оно сохраняется для операции remel(s,x), так как оно сохраняется для s (по предположению), а операция remel только удаляет элементы из s. Этот способ анализа называется индукцией типа данных.

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

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

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

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

Например, операция choose для наборов целых чисел имеет смысл, только если ее аргумент - не пустой набор. В приведенной выше спецификации типа данных intset (рис.1.9) эта ситуация учитывалась использованием процедуры choose, заданной на некоторой области определения. choose = proc (s: intset) returns (int) requires набор s не пуст effects Возвращает произвольный элемент s Но в этом случае, реализуя операцию choose, игнорируется случай пустого множества. Такие процедуры приводят к неустойчивым программам.

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

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

Однако это не самое лучшее решение.

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

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

Проверка на нелегальные аргументы может быть отключена только при абсолютной уверенности в невозможности ошибки или если проверка приводит к крайней неэффективности. Чтобы специфицировать процедуры, которые вызывают исключительные ситуации, добавим в спецификацию предложение signals. Это предложение - часть заголовка. Оно следует за предложением returns. Если исключительных ситуаций не имеется, оно может быть опущено. Как и раньше, секция effects должна определять поведение процедуры для всех фактических аргументов, отвечающих предложению requires. Так как это поведение включает в себя исключительные ситуации, секция effects должна определять, что приводит к вызову каждой исключительной ситуации и что делает процедура в каждом таком случае.

Завершение процедуры оповещением об исключительной ситуации - это один из нормальных режимов работы этой процедуры. С учетом всего вышесказанного, спецификация процедуры choose будет иметь вид: choose = proc (s: intset) returns (int) signals (empty) effects Если size(s)=0, то сигнализировать об исключительной ситуации empty, иначе возвратить произвольный элемент s. При реализации процедуры с исключительными ситуациями работа программиста заключается в том, чтобы обеспечить соответствующую спецификации работу процедуры. Если спецификация включает в себя исключительные ситуации, программа должна в нужное время сигнализировать о соответствующих исключительных ситуациях и передавать определенные в спецификации значения. Для выполнения этой задачи, программа, возможно, должна будет обрабатывать исключительные ситуации, возникающие в процедурах, к которым она обращается.

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

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

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

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

Рассмотрим в качестве примера спецификацию упорядоченных списков, в операциях которой удалены предложения requires и добавлены исключительные ситуации в операциях addel, remel и least. Полученная в результате спецификация (рис.1.14) будет обладать большей устойчивостью по сравнению с исходной (рис.1.13). olist = data type [t:type] is create,addel,remel,is_in,empty,least Requires - t имеет операции equal,lt:proctype(t,t) returns (bool), которые определяют упорядочение t Описание Упорядоченные списки olist - изменяемые списки элементов.

Операции addel и remel модифицируют списки.

Каждый элемент упорядоченного списка отличается от остальных (как определяется t.equal). Операция least возвращает наименьший элемент olist (как определяется t.lt) Операции create = proc () returns (olist [t]) effects возвращает новый, пустой список addel = proc (s: olist[t], x:t) signals(dupl) modifies s effects если x принадлежит s, сигнализирует об исключительной ситуации dupl, иначе вставляет x в s remel = proc (s: olist[t], x:t) signals(not_in) modifies s effects если x не принадлежит s, сигнализирует об исключи тельной ситуации not_in,иначе удаляет x из s is_in = proc (s: olist[t], x:t) returns (bool) effects возвращает значение true, если s содержит элемент равный x (используется t.equal), в противном случае возвращает значение false empty = proc (s: olist[t]) returns (bool) effects возвращает значение true, если s не содержит элементов, и значение false - в противном случае least = proc (s: olist[t]) returns(t) signals(empty) effects если s пуст, сигнализирует об исключительной ситуа ции empty, иначе возвращает элемент e из s, такой, что в s не существует элемента, меньшего e(как определяется t.lt) end olist Рис.1.14.Спецификация параметризованной абстракции данных для упорядоченных списков.

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

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

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

Например, рассмотрим процедуру addel = proc (s: olist[t], x:t) signals(dupl) modifies s effects если x принадлежит s, сигнализирует об исключительной ситуации dupl, иначе вставляет x в s Так как для случая, когда процедура addel сигнализирует об исключительной ситуации dupl, не описано никаких модификаций, s модифицируется только при обычном возврате из процедуры addel. Исключительная ситуация failure является неявной исключительной ситуацией каждой процедуры, однако она не упоминается ни в каких спецификациях.

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

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

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

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

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

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

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

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

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

Заголовок имеет вид: iname = iter(список входных данных) yields(список выходных данных) signals (сообщение об исключительной ситуации) Ключевое слово iter используется для обозначения абстракции итератора.

Итератор может совсем не выдавать объектов на каждой итерации или выдать несколько объектов. Число и тип этих объектов описываются в предложении yields. Итератор может не выдавать никаких результатов, когда он заканчивается нормально, но он может заканчиваться по исключительной ситуации с именем и результатами, указанными в предложении signals. Например, elements = iter (s: intset) yields (int) requires s не модифицируется в теле цикла effects Выдает элементы s в некотором произвольном порядке, причем каждый элемент только один раз. Эта операция вполне правдоподобна для набора intset. Операция elements не имеет исключительных ситуаций. Если ей будет задан в качестве аргумента пустой набор intset, она просто заканчивается, не выдавая ни одного элемента.

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

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

Итераторы являются механизмом, решающим эту задачу.

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

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

Рассмотрим по очереди абстракции процедур, данных и итераций, а затем приведем пример их использования. 1.6.1.Абстракции процедур и функций 1. В общем случае нецелесообразно проектировать абстракции, которые зависят от глобальных переменных, поскольку тогда знание такой абстракции бкдет зависеть от того контекста, в котором она находится. 2. Для обработки исключительных ситуаций в программах на языке Паскаль зададим некоторую процедуру failure. Эта процедура помещается в начало программы, и к ней может обращаться любая операция в этой программе. procedure failure (s:error_msg) modifies выходной поток на основном устройстве вывода effects печатает следующую строку на основном устройстве вывода: 'Сбой.

Программа окончилась из-за: +S', а затем выполнение программы останавливается 1.6.2.Абстракции данных В общем случае эти абстракции могут быть основаны на объектах, запоминаемых в стеке, и на объектах, хранящихся в неупорядоченном массиве.

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

Зададим спецификацию абстракции данных для очереди целых чисел. intqueue = data type is q_new, q_isempty, q_append, q_remfirst Описание Типы данных intqueue используются для хранения значений типа целого числа.

Элементы могут извлекаться из очереди или удаляться из нее только по методу FIFO (First Input-First Output) Операции function q_new:intqueue effects Возвращает новую очередь без элементов в ней function q_isempty (q:intqueue): boolean effects Возвращает значение true, если в очереди q нет элементов, в противном случае возвращает значение false procedure q_append (q:intqueue; e:integer) modifies q effects Добавляет элемент e в конец очереди q function q_remfirst (q:intqueue): integer requires чтобы очередь q не была пустой modifies q effects Возвращает элемент из начала очереди q и удаляет этот элемент из очереди q end intqueue Рис.1.15.Спецификация абстракции данных для очереди целых чисел.

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

Реализация такого абстрактного типа данных использует указатель на неупорядоченный массив. То есть при передаче в процедуру некоторого абстрактного объекта всегда передается только ссылка. При модификации абстрактного объекта, модифицируется тот объект, на который указывает ссылка, а не сама ссылка. Таким образом, абстрактные объекты введенного типа никогда не передаются, как параметры типа var. Кроме того, представление объекта некоторой ссылкой гарантирует то, что абстрактные объекты могут быть возвращены при помощи функций. В результате тип intqueue будет иметь следующее представление type intqueue = ^intqueue_rep; intqueue_rep = ^intqueue_elem; intqueue_elem = record var : integer; next : intqueue_rep; end; Теперь для объявления переменных некоторого абстрактного типа достаточно указать var q:intqueue; Смысл этого объявления состоит в том, что в стеке отводится пространство для некоторой неинициализированной переменной q. Когда очередь q объявлена, выделяется только указатель, а при выходе из процедуры, освобождается только этот указатель. Чтобы гарантировать правильное освобождение пространства, для каждого типа должна существовать некоторая дополнительная операция, называемая destroy. procedure q_desstroy (q:intqueue) modifies q effects В неупорядоченном массиве освобождается вся память, занимаемая очередью q По соглашению нельзя освобождать абстрактные объекты непосредственно.

Вместо этого необходимо обращение к операции destroy для типа данного объекта. На рис.1.16 приведена реализация типа данных intqueue, включая и операцию destroy. Type IntQueue = ^IntQueue_Rep; IntQueue_Rep = ^IntQueue_Elem; IntQueue_Elem = Record i : Word; Next : IntQueue_Rep; End; Function q_new:IntQueue; Function q_isempty(q:IntQueue):Bollean; Procedure q_append(q:IntQueue; e:Word); Function q_remfirst(q:Intqueue):Word; Procedure failure(s:String); Function q_new:IntQueue; Var q:IntQueue; Begin new(q); q^:=nil; q_new:=q; End; Function q_isempty(q:IntQueue):Bollean; Var buf:bollean; Begin buf:=(q^=nil); q_isempty:=buf; End; Procedure q_append(q:IntQueue; e:Word); Var last,elem:IntQueue_Rep; Begin new(elem); elem^.i:=e; elem^.next:=nil; if q_isempty(q) then q^:=elem else begin last:=q^; while last^.next <> nil do last:=last^.next; last^.next:=elem; end; End; Function q_remfirst(q:IntQueue):Word; Var oldq:IntQueue_Rep; Begin if q_isempty(q) then failure (' К функции q_remfirst обратились с пустой очередью') else begin q_remfirst:=q^^.i; oldq:=q^; q^:=q^^.next; dispose(oldq); end; End; Procedure failure(s:String); Begin OutTextXT(320,200,s); Readln; Halt(0); End; Рис .1.16. Реализация операций типа данных intquaeue. 1.6.3.Абстракция итерации Для реализации итератора создадим тип некоторого специального вида, называемый генератором.

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

Процедура уничтожает объект генератора.

Например, для очереди целых чисел создадим генератор qelems (рис.1.17). Функция qelems_create выполняет некоторую работу по инициализации, то есть возвращает некоторый объект с типом qelems. Вторая функция qelems_next выдает каждый раз один элемент при обращении к ней и модифицирует объект генератора qelems, чтобы указать, что этот элемент уже был выдан.

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

Процедура qelems_destroy освобождает пространство, которое было выделено при работе функцией qelems_create и qelems_next. qelems = generator type is qelems_create, qelems_done, qelems_next, qelems_destroy Описание Генераторы qelems используются для выполнения итераций по элементам очередей целых чисел IntQueue. Операции function qelems_create (q:IntQueue): qelems effects Возвращается некоторый объект qelems, который может быть использован для выдачи всех элементов в очереди q function qelems_done (qi:qelems): boolean requires Чтобы очередь целых чисел intqueue, используемуя для создания элементов qi, не модифицировалась после того, как создан элемент qi effects Возвращается значение true, если все элементы в очереди целых чисел intqueue, используемой для создания элементов qi, были 'выданы' после того, как был создан элемент qi. В противном случае возвращается значение false function qelems_next (qi:qelems): word requires Чтобы очередь целых чисел intqueue, используемуя для создания элементов qi, не модифицировалась после того, как создан элемент qi, и чтобы существовал некоторый элемент в очереди целых чисел intqueue, который еще не был выдан modifies qi effects Возвращается некоторый элемент в очереди чисел intqueue, используемой для создания элемента qi. Этот элемент очереди не был выдан после того, как был создан элемент qi. Элемент qi модифицируется для того, чтобы отметить тот факт, что данный элемент был ' выдан ' procedure qelems_destroy (qi:qelems) modifies qi effects Освобождается вся память из неупорядоченного массива, занимаемая элементом qi end qelems Рис.1.17.Спецификация типа данных генератор для очередей.

Реализация операций над типом данных qelems, совместная с реализацией очереди целых чисел intqueue, имеет вид: type qelems = ^qelems_rep; qelems_rep = ^intqueue_elem; function qelems_create (q:intqueue): qelems; var qi:qelems; begin new(qi); qi^:=q^; qelems_create:=qi; end; function qelems_done (qi:qelems): bollean; begin qelems_done:=(qi^=nil); end; function qelems_next (qi:qelems): word; begin if qi^=nil then failure(' К функции qelems_next обратились с пустой очередью генератора') else begin qelems_next:=qi^^.i; qi^:=qi^^.next; end; end; procedure qelems_destroy (qi:qelems); begin dispose(qi); end; Рис .1.18. Реализация генератора для типа данных очередь целых чисел intqueue. В результате этой реализации осуществляется доступ к представлению очереди целых чисел intqueue. Следует отметить, что представление имеет дополнительный уровень косвенности для того, чтобы гарантировать правильность совместимого использования.

Пример суммирования всех членов очереди примет вид: sum:=0; qi:=qelems_create(q); while not (qelems_done(qi)) do sum:=sum+qelems_next(qi); qelems_destroy(qi); 2.ВВЕДЕНИЕ В ИНЖЕНЕРНОЕ ПРОГРАММИРОВАНИЕ 2.1.Цели и задачи инженерного программирования П р о г р а м м н о е о б е с п е ч е н и е - это совокупность программ, процедур работы и соответствующей документации для вычислительной системы(ВС). И н ж е н е р н о е п р о г р а м м и р о в а н и е - это такое применение естественных и математических наук, в результате которого потенциальные возможности ЭВМ реализуются на пользу человеку с помощью машинных программ, организационных процедур и соответствующей документации.

Стоимость и качество производимого ПО определяются уровнем развития инженерного программирования.

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

Стоимость ПО, разработанного в США, характеризуется следующими данными. Табл.2.1.Стоимость ПО в США Стоимость ПО Годы млрд $ %% ВНП 1980 40 2,0 1985 190 8,5 1990 297 13,0 Общемировые тенденции роста стоимости ПО можно проиллюстрировать тем, что стоимость ПО по сравнению со стоимостью технических средств вычислительной техники имеет более высокий темп роста (рис.2.1) Западноевропейская оценка Доля пол- 100 --------------------------- ................. ной стои- | | .......|........ .. .. мости, %% | ТС | .... | .. .. .. | ..|. | .. .. .. .. | .. | | .. .. 50 |------------|------------| Японская оценка | . | | | . | | | ... | ПО | |.. | | 0 --------------------------- 1955 1970 1985 Рис.2.1.Тенденции изменения стоимости ТС и ПО Подобный рост спроса на ПО предъявляет существенные требования к инженерному программированию: - существенно повысить производительность труда при разработке ПО; - повысить эффективность сопровождения ПО, так как оно составляет около половины стоимости ПО (рис.2.1). Рост спроса на ПО является следствием того, что автоматизация труда человека с помощью ЭВМ становится все более и более выгодной. Эта тенденция может быть подтверждена следующими данными. В настоящее время в США более половины работающих используют ЭВМ в своей профессиональной деятельности, не обязательно зная как функционируют ТС и ПО. То есть, они неявно полагались на правильность результатов применения ПО. Еще более глубокое воздействие ЭВМ и ПО оказывают на частную жизнь.

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

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

Пример противоречий: пяти бригадам программистов дано одно и то же задание по программированию.

Однако перед разными бригадами были поставлены разные цели. Табл.2.2.Оценки результатов работы бригад Цель бригады - Оценки (1-наилучшая, 5-наихудшая) оптимизировать затраты число опеобъем ясность четкость труда операторов памяти програм. данных Затраты труда 1 4 4 5 3 Число операторов 2 1 2 3 5 программы Объем требуемой 5 2 1 4 4 памяти Ясность программы 4 3 3 2 2 Четкость выходных 3 5 5 1 1 данных Как видно, область инженерного программирования к счастью (или к несчастью) не столь проста.

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

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

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

Эффективность инженерного программирования основывается на осуществлении двух основных подцелей: - получение качественного программного изделия - реализация эффективного процесса разработки и сопровождения ПО. Каждая из этих подцелей состоит из следующих трех компонентов: - учет человеческих факторов - управление ресурсами - программотехника (технология программирования). В общем случае цели инженерного программирования можно представить следующей иерархической структурой (рис.2.2). Эффективность инженерного программирования Качество программного Эффективность процесса изделия разработки ПО Человеч.

Управлен ПрограмЧеловеч.

Управлен Програмфакторы ресурсам мотехник факторы ресурсам мотехник Легкость ЭффективСпецифициПланируеАнализируОсуществииспользова ность рованность: мость емость эфмость ния Сбалансиполнота Организуфективности ПодтвержУдовлетворованность непротивоемость затрат даемость рение потИзмеряеречивость УкомплекПланируеПолнота и ребностей мость безопастованность мость непротивопользоватеность штатов Оцениваеречивость ля осуществиРуководимость требований Реализация мость мость КонтролиПодтверждапотенц.спопроверяеКонтролируемость емость собностей мость руемость ВыполняеПроектируепользоватеПравильАвтоматимость мость изделя ность зируемость сроков и лия Следование АдаптируСледование бюджета Программимодифицир. емость: модифицир. руемость 'золотому' структури- 'золотому' Комплексиправилу рованность правилу руемость независиВнедряемость мость понятность Сопровождаемость Снимаемость Управляемость конфигурацией Рис.2.2.Структура целей инженерного программирования. 2.2.Типы пользователей 2.2.1.Уровни пользователей ПО Можно выделить три квалификационные категории пользователей, которые занимаются разработкой и использованием программного обеспечения. К первому уровню относятся разработчики ПО - специалисты в области применения ЭВМ, способные разрабатывать базовые методы, средства и оснащение ПО, общесистемное ПО, инструментальные и технологические средства, осуществлять генерацию и настройку ПО на условия конкретного применения. Ко второму - те, кто хорошо знает тонкости построения системы и может ее модифицировать, то есть прикладные программисты, которые знают методологию проектирования, алгоритмы прикладной области и могут разрабатывать специализированное ПО, используя общесистемное ПО. К третьему относятся пользователи, работающие в системе с помощью ориентированного на них языка взаимодействия.

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

Наиболее удачным является сочетание когда ЭВМ реализует отдельные расчетные процедуры, а их логическая последовательность определяется человеком - создателем проектируемого объекта. С п о с о б н о с т ь к о б у ч е н и ю.

Человек обучается постепенно, степень 'образованности' ЭВМ определяется ее программным обеспечением.

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

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

Эффективность вторичного обращения к памяти зависит от времени. В ЭВМ емкость памяти большая, организация формальная и детализированная, вторичное обращение не зависит от времени.

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

Человек умеет хорошо разделять значимую и несущественную информацию. ЭВМ таким свойством не обладает.

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

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

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

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

Человеку трудно воспринять большое количество информации.

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

Естественно, что изменения, сделанные в одной из этих частей, должны автоматически производиться во всех остальных. Р а с п р е д е л е н е в н и м а н и я н а н е с к о л ь - к о з а д а ч.

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

Поэтому в ЭВМ организована система прерываний, восстанавливающая состояние основной задачи к моменту, нужному для пользователя.

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

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

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

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

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

Исходные команды не включают комментарии и штатное ПО, но включают операторы языка управления заданиями, операторы флрмата и описание.

Исходя из числа исходных команд (ЧИК) можно классифицировать ПО следующим образом по размеру: Малый........... 2 000 ЧИК Промежуточный... 8 000 ЧИК Средний......... 32 000 ЧИК Большой.........128 000 ЧИК Введем следующие обозначения. Будем считать, что человеко-месяц (ЧМ) состоит из 152 часов рабочего времени. Тогда для преобразования можно использовать следующие правила: для получения человеко-часов....умножить ЧМ на 152 для получения человеко-дней.....умножить ЧМ на 19 для получения человеко-годов....разделить ЧМ на 12 Если возможна предварительная оценка разрабатываемого ПО в тысячах исходных команд (КЧИК), то затраты труда в ЧМ и сроки разработки могут быть определены уравнениями 1,05 0,38 ЧМ=2,4*(КЧИК) СР=2,5*(ЧМ) Эти же данные можно представить следующей таблицей. Табл.2.3.Характеристики проектов распространенного типа Размер ПО, КЧИК Затраты ПроизводительСроки, Средние труда, ЧМ ность, ЧИК/ЧМ месяцы штаты, ЧИ Малый, 2 5,0 400 4,6 1,1 Промежуточный, 8 21,3 376 8,0 2,7 Средний, 32 91,0 352 14,0 6,5 Большой, 128 392,0 327 24,0 16,0 Приведенные в табл.2.3 данные относятся к коммерческим программным продуктам, подразумевающим тщательное документирование, отладку, обеспечение надежности при наличии ошибок, обучение пользователей и т.п.

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

Данные табл.2.3 получены на основании анализа 63 проектов разработки ПО для разных типов ЭВМ, разных объемов, разного назначения, используюшего различные языки программирования.

Второй характеристикой для классификации ПО может служить качественная оценка.

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

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

Другими характерными чертами ПО распространенного типа являются следующие: - стабильные условия разработки проекта; - минимальная необходимость новых системных и алгоритмических решений; - относительно малое поощрение за раннее завершение проекта; - относительно малый размер (как правило, до 50 КЧИК). В с т р о е н н ы й тип отличается от других жесткими ограничениями на характеристики ЭВМ и правила использования интерфейса. Такое изделие должно работать при тесной взаимосвязи аппаратуры, программ, руководств и вычислительных процессов. (Пример - система резервирования авиабилетов или система управления воздушным движением). При разработке встроенного ПО, как правило, отсутствует возможность договориться об уменьшении изменений и исправлений в программах при модификации требований и интерфейса.

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

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

Обычно не превосходит 300 КЧИК. Теперь можно расширить табл.2.3 характеристиками для двух других типов (табл.2.4). Табл.2.4.Оценки для разработки ПО разных типов ХаракТип разОценки для размеров терисработки тики малый, промежусредний большой очень большой 2 КЧИК точный, 32 КЧИК 128 КЧИК 512 КЧИК 8 КЧИК Затраты Распр. 5,0 21,3 91 397 труда, Полун. 6,5 31,0 146 687 3250 ЧМ Встр. 8,3 44,0 230 1216 6420 Произво Распр. 400 376 352 327 дительПолун. 308 258 219 186 158 ность, Встр. 241 182 139 105 80 ЧИК/ЧМ Сроки Распр. 4,6 8,0 14 24 разраПолун. 4,8 8,3 14 24 42 ботки, Встр. 4,9 8,4 14 24 42 месяцы Среднее Распр. 1,1 2,7 6,5 16 число Полун. 1,4 3,7 10,0 29 77 исполни Встр. 1,7 4,2 16,0 51 157 телей 1.05 4M = 2.4*КЧИК - распространенный 1.12 4М = 3.0*КЧИК - полунезависимый 1.20 4М = 3.6*КЧИК - встроенный 2.4.Жизненный цикл программного обеспечения Рассмотрим жизненный цикл программного обеспечения, то есть процесс его создания и применения от начала до конца. Этот процесс состоит из нескольких стадий: определения требований и спецификаций, проектирования, программирования, отладки и сопровождения.

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

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

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

Функциональные спецификации определяют функции, которые должно выполнять ПО, то есть в них определяется что надо делать, а не как это делать.

Спецификации должны быть полными, точными и ясными.

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

Точность не позволяет различных толкований.

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

Значение спецификаций: 1.спецификации являются заданием на разработку ПО и их выполнение - закон для разработкчика; 2.спецификации используются для проверки готовности ПО; 3.спецификации являются неотемлимой частью программной документации, облегчают сопровождение и модификацию ПО. Второй стадией является проектирование ПО. На этом этапе: 1.формируется структура ПО и разрабатываются алгоритмы, задаваемые спецификациями; 2.устанавливается состав модулей с разделением их на иерархические уровни на основе изучения схем алгоритмов; 3.выбирается структура информационных массивов, составляющих базу данных; 4.фиксируются межмодульные интерфейсы. Цель этапа - иерархическое разбиение сложных задач создания ПО на подзадачи меньшей сложности.

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

Третья стадия - программирование. На данном этапе производится программирование модулей. Этап менее сложен по сравнению со всеми остальными.

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

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

Распределение временных и стоимостных затрат по отдельным стадиям жизненного цикла программного обеспечения представлено в табл.2.5 и 2.6. Табл.2.5.Затраты по стадиям жизненного цикла ПО Сведения из разных источников Стадии жизненного Гласс Р. ЭнкарначБоэм Б. Федорчук Вишняцикла программного Нуазо Р. чо Ж. Черненьков Среднее обеспечения кий Определение требо- 10 15 6 6 6 8,6 ваний и специфик.

Проектирование 10 12 18 5 6 10,2 Программирование 10 12 9 7 6 8,8 Отладка 20 15 17 15 14 16,2 Сопровождение 50 46 50 67 68 56,2 Всего 100 100 100 100 100 100 Табл.2.6.Основные параметры стадий жизненного цикла ПО Стадии жизненного Количество ОбнаружеЗатраты на цикла программного ошибок,%% ние ошибок устранение обеспечения %% ошибок,%% Определение требо- 9 ваний и спецификаций Проектирование 61-64 6 Программирование 36-39 10 Отладка 46 12 Сопровождение 54 63 Основные временные соотношения между отдельными видами работ можно представить сетевым графиком разработки ПО. 13 13 8 Разработка ПроектироДокументитребований вание рование 8 8 Подготовка Начало данных для Программирование Конец отладки ПланироваРазработка Испытание ние отладки драйверов программнотестов го изделия 8 25 17 Рис.2.7.Сетевой график разработки ПО. (цифры означают время в %% от полного времени первых четырех этапов жизненного цикла) 2.5.Общие принципы разработки ПО 2.5.1.Общие принципы Программное обеспечение различается по назначению, выполняемым функциям, формам реализации. В этом смысле ПО - сложная, достаточно уникальная программная система.

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

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

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

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

Программы, входящие в состав монитора, постоянно хранятся в оперативной памяти.

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

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

Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи данных из-за психологических различий в восприятии информации. П р и н ц и п 'п о у м а л ч и в а н и ю'. Применяется для облегчения организации связей с системой как на стадии генерации, так и при работе с уже готововым ПО. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций оборудования и данных, определяющих условия работы с ПО. Эту информацию ПО использует в качестве заданной, если пользователь забудет или сознательно не конкретизирует ее. В данном случае ПО само установит соответствующие значения. 2.5.2.Общесистемные принципы При создании и развитии ПO рекомендуется применять следующие общесистемные принципы: - принцип включения, который предусматривает, что требования к созданию, функционированию и развитию ПО определяются со стороны более сложной, включающей его в себя системы; - принцип системного единства, который состоит в том, что на всех стадиях создания, функционирования и развития ПО его целостность будет обеспечиваться связями между подсистемами, а также функционированием подсистемы управления; - принцип развития, который предусматривает в ПО возможность его наращивания и совершенствования компонентов и связей между ними; - принцип комплексности, который заключается в том, что ПО обеспечивает связность обработки информации как отдельных элементов, так и для всего объема данных в целом на всех стадиях обработки; - принцип информационного единства, то есть во всех подсистемах, средствах обеспечения и компонентах ПО используются единые термины, символы, условные обозначения и способы представления; - принцип совместимости, который состоит в том, что язык, символы, коды и средства обеспечения ПО согласованы, обеспечивают совместное функционирование всех его подсистем и сохраняют открытой структуру системы в целом; - принцип инвариантности, который предопределяет, что подсистемы и компоненты ПО инвариантны к обрабатываемой информации, то есть являются универсальными или типовыми. 3.АНАЛИЗ ТРЕБОВАНИЙ И РАЗРАБОТКА СПЕЦИФИКАЦИЙ 3.1.Общие положения Разработку программного обеспечения можно рассматривать как последовательность следующих действий: определение требований; составление спецификаций; проектирование логики; программирование; тестирование; документирование.

Условия Определение требований Анализ Функциональная архитектура Проектирование Архитектура системы Построение Операционная система Рис.3.1.Этапы построения системы. Два первых этапа имеют в основном аналитический характер, причем уровень этого анализа выше уровня проектирования и реализации новой системы. Их результатом является функциональная спецификация. На следующем этапе проектирования определяется архитектура системы.

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

Программирование и тестирование поддерживаются операционной системой.

Документирование необходимо на всех этапах разработки.

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

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

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

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

Необходимо ответить на следующие три основные вопроса: Условия Анализ внедрения Почему? Почему понадобилась система? системы (необходим анализ той среды, в которую система должна внедряться); Что система должна делать? Функциональная (в функциональной спецификации долспецификация Что? жны быть описаны наиболее важные возможности системы); Каким образом можно реализовать систему? (этот вопрос относится к ресурсам, Проектные которые могут понадобиться при реаограничения Как? лизации и эксплуатации системы, а также к ограничениям, налагаемым средой; вопрос о том, какие шаги необходимо предпринять для реализа- ции, будет поставлен позже в процессе разработки системы). Рис.3.2.Вопросы, возникающие в процессе разработки системы.

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

Такого рода описания определяют структуру задачи, но не решают ее.

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

Анализ системы, в результате которого определяется функциональная архитектура, должен проводится на таком уровне детализации, который позволит точно определить: - функциональные возможности системы (набор функций и налагаемые средой ограничения); - тип описания (на формальном или естественном языке); - критерии оптимизации (которые необходимы для нахождения разумного компромисса между противоречивыми требованиями). Из-за пренебрежения анализом требований и предварительным анализом осуществимости были прекращены такие проекты: - система стоимостью 56 млн долларов для предварительного заказа авиабилетов; - система стоимостью 217 млн долларов для материально-технического снабжения; Исправление ошибки на фазе сопровождения большого проекта обходится обычно в 100 раз дороже, чем исправление той же ошибки на фазе анализа требований (табл.2.6). Пример П1.Определение предметной области и начальных требований Рассмотрим весь комплекс вопросов, связанных с разработкой программного обеспечения, моделирующего работу центральных устройств ЭВМ - центрального процессора (ЦП) и оперативного запоминающего устройства (ОЗУ) в мультипрограммном режиме.

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

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

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

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

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

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

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

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

Возможные переходы из одного состояния в другое показаны на рисунке.

Ожидает Событие Блокирование события наступило Истек квант Активность времени Готовность В любой момент времени активным может быть только один процесс. При передаче управления процессу пользователя ОС устанавливает интервальный таймер, задавая тем самым квант времени, являющийся максимальным количеством времени ЦП, на которое процесс получает управление. Если это время истекает, процесс переводится из состояния активности в состояние готовности. После этого ОС, согласно стратегии планирования, выбирает следующий процесс, находящийся в готовности, переводит его в состояние активности и передает ему управление. Может оказаться, что активный процесс, не использовав полностью предоставленный ему квант времени, должен ожидать наступления некоторого события, например завершения операции I/O. В этом случае активный процесс блокируется, а какой-то другой готовый процесс активизируется.

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

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

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

Обслуживание очереди готовых процессов, как правило, осуществляется активизацией первого в очереди процесса. В наиболее простом случае, выбранному для активизации процессу разрешается использовать ЦП вплоть до своего завершения. Если очередь бесприоритетна, то такая стратегия называется FIFO (First In - First Out). В более сложной стратегии, называемой круговым циклическим алгоритмом (Robin Round), каждому активизируемому процессу предоставляется одинаковый квант времени, по истечении которого процесс либо завершается, либо возвращается в конец очереди для последующего обслуживания.

Приоритеты могут быть статическими и динамически изменяемыми. Если не рассматривать субъективное назначение приоритетов, связанное с типами пользователей и важностью программ, то наиболее существенным критерием для назначения приоритета является время ЦП, требуемое процессу. Более короткие по времени выполнения процессы должны обслуживаться раньше.

Реализация такой стратегии в ОС пакетной обработки получила название SJF (Shortest Job First). Процессу при его порождении присваивается приоритет в зависимости от требуемого времени ЦП, в соответствии с которым он ставится в очередь готовых процессов, а при активизации выполняется до конца. В ОС с разделением времени используют назначение неявных динамических приоритетов, когда каждый активный процесс, которому еще необходимо время ЦП, возвращается в конец менее приоритетной очереди. Такая стратегия называется стратегией обратных очередей или FB (Feed Back). Любая ОС, поддерживающая мультипрограммный режим работы, должна обладать механизмом разделения ОЗУ между совместно выполняющимися процессами.

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

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

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

Единой проблемой для обеих рассмотренных стратегий распределения памяти ОЗУ между загружаемыми модулями является фрагментация памяти, когда доступная свободная память разбита на несколько несмежных блоков, каждый из которых слишком мал для использования. Одно из возможных решений этой проблемы связано с использованием стратегии перемещаемых разделов. После окончания каждого задания оставшиеся разделы сдвигаются к одному из концов памяти. В результате этого вся доступная свободная память собирается в один общий блок, который больше подходит для распределения новых разделов. В зависимости от стоящих перед учебной дисциплиной целей необходимо иметь: - чисто визуальное моделирование взаимосвязанной работы центральных устройств ЭВМ по обслуживанию процессов; - более детальное моделирование с возможностью фиксации размещения отдельных заданий в ЦП и ОЗУ и временных интервалов обработки; - инструментальное средство для накопления статистической информации обслуживания процессов; - возможность генерации случайной последовательности обрабатываемых процессов с задаваемыми характеристиками распределения параметров.

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

Разрабатываемое ПО предполагает совместное моделирование центральных устройств ЭВМ. Учебный характер разрабатываемого программного обеспечения требует тщательной проработки формы и методов визуализации процесса моделирования и его результатов. Как можно реализовать систему моделирования работы центральных устройств ЭВМ? Очевидно, что для моделирования мультипрограммного обслуживания каждый процесс может быть представлен тремя параметрами: - требуемым временем обработки на ЦП; - временным интервалом порождения по отношению к предшествующему процессу; - требуемым объемом оперативной памяти.

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

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

Моделирование работы ЦП и ОЗУ должно быть осуществлено обработкой последовательности процессов в соответствии с назначаемыми стратегиями и с помощью процедур и функций вводимых типов данных. 3.2.Документирование требований 3.2.1.Цели документации требований Для того, чтобы документация требований была согласованной и полезной, необходимо принять явные решения относительно целей, которым она должна служить. Ее содержание, организация и стиль зависят от решений, принятых по следующим вопросам: - на какие вопросы документация должна давать ответы? - кто ее читатели? - как ее будут использовать? - какие предварительные знания нужны читателю? Исходя из этих вопросов целями документирования требований являются следующие шесть пунктов. 1.Задавать только внешнее поведение.

Описание требований должно задавать лишь внешнее поведение системы и не навязывать какой-либо конкретной реализации. 2.Задавать ограничения на реализацию. Кроме определения корректного поведения программы, требования должны содержать ограничения, накладываемые на реализацию, особенно в части интерфейсов с внешним окружением. 3.Быть легко изменяемым.

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

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

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

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

Таблица 3.1.Примерное оглавление документа требований Глава Содержание Введение Принципы организации документа; краткое содержание остальных глав; обозначения 1.Характеристики ЭВМ Если ЭВМ задана заранее, то ее общее описание с учетом специфических черт; в противном случае - основные требования к ЭВМ 2.Интерфейсы с внешним Краткое описание информации, получаемой окружением и передаваемой разрабатываемой системой 3.Функции программы Что должна делать программа, чтобы удовлетворять требованиям в разных ситуациях; какой должна быть ее реакция на различные события 4.Временные ограничеКак быстро и как часто должна выполняться ния каждая из функций. Этот аспект рассматривается отдельно от главы 3, так как ответы на вопросы 'что?' и 'когда?' изменяются независимо 5.Требования к точносКаковы допустимые отклонения выходных пати раметров от точных значений 6.Реакция на нежелаЧто программа должна делать при выходе из тельные события строя аппаратуры и датчиков, получении некорректных данных от пользователя и т.п 7.Подмножества Какие части системы необходимо сделать легко удаляемыми 8.Фундаментальные Характеристики программы, которые не изпредположения меняются ни при каких модификациях 9.Изменения Типы внесенных или ожидаемых изменений 10.Глоссарий Затем готовятся вопросы по каждой главе. Как и всякая работа по проектированию, постановка вопросов носит итеративный характер. 2.Разделять аспекты. Смысл состоит в сосредоточении на хорошо определенной совокупности вопросов.

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

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

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

Каждый из трех случайно генерируемых параметров процесса будет измеряться натуральным числом из интервала от 1 до 9. Этими числами будут определяться условные единицы времени и памяти ОЗУ. В качестве стратегий распределения времени ЦП между различными процессами приняты следующие : - стратегия очередей (первым пришел - первым обслужен); - планирование по приоритету (обслуживание первыми самых кратких); - круговой циклический алгоритм; - очередь с обратной связью.

Моделирование работы ОЗУ осуществляется для следующих стратегий распределения памяти: - с разделами фиксированного размера; - с разделами переменного размера; - с перемещаемыми разделами.

Разнообразные цели использования разрабатываемого программного обеспечения требуют нескольких форм визуализации процессов моделирования: - раздельного представления, для возможности изучения работы либо ЦП, либо ОЗУ; - совместного представления, но либо в виде моделируемых устройств c интерпретацией обрабатываемых процессов, либо в виде накапливаемой статистической информации. 3.3.Анализ требований Предлагаемое заказчиком исходное описание программы обычно не является ни полным, ни точным.

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

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

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

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

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

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

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

Хорошим подходом может служить разработка сценариев всех типовых взаимодействий с системой.

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

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

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

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

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

Конечной целью анализа требований является составление функциональной спецификации.

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

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

Пример П3.Функциональная спецификация Полученная в результате анализа требований функциональная спецификация системы моделирования работы центральных устройств ЭВМ имеет следующий вид. 1.Общие требования к системе 1.1.Пользователю должна быть предоставлена возможность выбора в любой момент работы с программой установки исходных данных, моделирования или просмотра накапливаемой статистической информации. 1.2.При выборе пользователем режима моделирования в начальный момент сеанса работы программа должна по умолчанию установить все требуемые параметры, включая генерацию последовательности процессов с равномерным распределением. 1.3.Программа должна быть застрахована от некорректных действий пользователя, указывая ему на то, что необходимо исправить, или осуществляя программную корректировку. 1.4.Программа должна сама выяснять тип видеоадаптера и осуществлять настройку. 1.5.По желанию пользователя должна быть возможной настройка используемых программой цветов. 1.6.Для единообразия масштабов шкала ординат в гистограммах процессов должна быть логарифмической (0, 1, 10, 100, 1000, 10000) 1.7.В любой момент сеанса работы пользователь должен иметь возможность распечатки накопленной статистической информации. 2.Установка параметров 2.1.Программа должна обеспечивать генерацию или выбор сохраненной последовательности процессов, выбор способа визуализации моделируемых устройств и стратегий их работы, установку числовых значений различных параметров. 2.2.Длительность процесса, интервал его порождения по отношению к предшествующему процессу и объем требуемой памяти определяются случайными натуральными числами в интервале от 1 до 9. 2.3.Распределение длительности, интервала порождения и требуемого объема памяти для процессов выборки должно быть равномерным по умолчанию или регулируемым при желании пользователя для каждого из генерируемых параметров. 2.4.Количество процессов, генерируемых программой для статистической выборки, устанавливается пользователем или равно 100 по умолчанию. 2.5.Количество процессов, генерируемых программой свыше заданного числа выборки, равно десяти по умолчанию. Пять из них - начальные, с временем порождения, равным нулю, пять - конечные, с произвольным временем порождения. 2.6.Пользователь по желанию может изменять количество начальных и конечных процессов. 2.7.Последовательность процессов может сохраняться при желании пользователя на протяжении сеанса работы для изучении различных стратегий, а также может быть сохранена в базе данных для последующих сеансов работы. 2.8.Стратегии планирования работы ЦП должны быть следующими: - стратегии очередей: - первым пришел, первым обслужен (First In First Out); - планирование по наивысшему приоритету (Highest Priority First): - обслуживание первыми самых кратких (Shortest Job First); - круговой циклический алгоритм (Round Robin); - очередь с обратной связью (Feed Back): - переход в низшую очередь после получения кванта времени ЦП в режиме кругового циклического алгоритма. 2.9.Стратегии распределения ОЗУ должны должны быть следующими: - с разделами фиксированного размера; - с разделами переменного размера; - с перемещаемыми разделами. 2.10.Выбор способа визуализации моделируемых устройств и стратегий их работы осуществляется пользователем или устанавливается по умолчанию. 2.11.Объем памяти ОЗУ принимается равным 100 условным единицам памяти по умолчанию или задается пользователем, но не более 100 и кратно 10. 10% объема ОЗУ автоматически отводится под ядро операционной системы. 2.12.При выборе стратегии распределения ОЗУ на разделы фиксированного размера количество разделов и объем каждого из них определяется пользователем. 2.13.При изучении стратегий планирования центрального процессора память ОЗУ должна распределяться по умолчанию на перемещаемые разделы. 2.14.При изучении распределения памяти ОЗУ планирование центрального процессора должно реализовываться по круговому циклическому алгоритму по умолчанию. 3.Моделирование работы центральных устройств 3.1.Программа должна обеспечивать совместную или раздельную визуализацию моделирования работы центрального процессора (ЦП) и оперативного запоминающего устройства (ОЗУ) при различных стратегиях планирования и распределения. 3.2.При визуализации моделирования работы одного из центральных устройств программа должна обеспечивать возможность работы другого устройства в соответствии с принятой пользователем или устанавливаемой по умолчанию стратегией. 3.3.Величина кванта времени предоставления ЦП процессу в соответствующих стратегиях планирования равна одной условной единице времени по умолчанию. 3.4.Работа программы при моделировании должна допускать автоматический и пошаговый режимы. Под шагом понимается единица времени.

Переход от одного режима к другому в процессе работы программы произволен. 3.5.При изучении стратегий планирования ЦП на экране должна присутствовать следующая информация: - время (условные единицы); - процесс - обладатель ЦП; - очереди процессов; - накапливаемая статистическая информация в графической форме. 3.6.При изучении стратегий распределения ОЗУ на экране должна присутствовать следующая информация: - время (условные единицы); - процессы, находящиеся в ОЗУ (в графической форме); - текущая загрузка ОЗУ в %%; - накапливаемая статистическая информация в графической форме. 3.7.При изучении совместной работы центральных устройств на экране должна присутствовать информация согласно п.3.5 и 3.6. 3.8.Процесс моделирования должен осуществляться вплоть до завершения обработки последнего процесса выборки. 3.9.Должна быть предусмотрена возможность прерывания процесса моделирования (с подтверждением) и выхода в главное меню программы. 3.10.Каждый процесс во время моделирования должен иметь следующие характеристики: - последовательный номер - длительность начальные сведения, генерируемые - требуемый объем памяти программой - время порождения - время постановки в очередь (загрузка в ОЗУ); - время первого предоставления ЦП; - время завершения обслуживания (время выгрузки из ОЗУ). 3.11.Накапливаемая статистическая информация для процессов выборки при изучении стратегий планирования ЦП должна включать: - длительность процесса; - количество процессов с одинаковой длительностью; - суммарный интервал от момента порождения до момента постановки в очередь (загрузки в ОЗУ); - средний интервал от момента порождения до момента постановки в очередь (загрузки в ОЗУ); - суммарный интервал от момента постановки в очередь (загрузки в ОЗУ) до момента первого предоставления ЦП; - средний интервал от момента постановки в очередь (загрузки в ОЗУ) до момента первого предоставления ЦП; - суммарный интервал обслуживания (время нахождения в ОЗУ); - средний интервал обслуживания (время нахождения в ОЗУ). 3.12.Накапливаемая статистическая информация при изучении стратегий распределения ОЗУ должна включать: - гистограмму загрузки; - среднюю загруженность памяти. 3.13.Накапливаемая статистическая информация до завершении моделирования любой из стратегий работы центральных устройств по желанию пользователя может быть представлена в числовом виде. 3.14.Накапливаемая статистическая информация по завершении моделирования любой из стратегий работы центральных устройств по желанию пользователя может быть сохранена в базе данных системы. 4.Просмотр накопленной статистической информации 4.1.Программа должна обеспечивать просмотр и удаление накопленной в файлах базы данных статистической информации для любого сохраненного в них сочетания стратегий обслуживания ЦП и ОЗУ, а также возможность просмотра информации для нескольких сочетаний. 4.2.Пользователю должна быть предоставлена возможность просмотра накопленной статистической информации в числовом и графическом виде.

Полученная функциональная спецификация должна иметь результатом функциональную структуру программного продукта.

Пример П4.Функциональная структура системы моделирования ЦП и ОЗУ УСТАНОВКИ Локальная режимов мобаза делирования данных База МОДЕЛИРОВАМодуль данных НИЕ работы отображесистемы ЦП и ОЗУ ния Модуль ПРОСМОТР Модуль обработки накопленной визуализакоманд информации ции Команды Информация пользователя для экрана - данные; - управление. !!!!!!!!!!! Дальше пока читать не нужно !!!!!!!!!!!!!!!! 3.5.HIPO-технология (HIPO - Hierarchical Input Process Output Diagramms) Методология HIPO на основе графических диаграмм (IBM) является наиболее известной для реализации нисходящего проектирования. В этой методологии предусмотрено три вида диаграмм.

Диаграммы первого типа - вспомогательные - предназначены для окончательного оформления программной документации. С помощью диаграмм второго типа, иерархических, постепенно проектируется полная структура ПО. Монитор A B C A1 A2 A3 C1 C2 A11 A12 A31 C11 Рис.3.10. Вариант структуры программного обеспечения.

Каждый модуль этой диаграммы представляется диаграммой 'вход - обработка - выход'. Функции модуля Входные 1................. Выходные данные 2................. данные 3................. Рис.3.11. IPO-диаграмма Спецификации, составленные с помощью метода HIPO, представляют альбом связанных между собой схем, каждая из которых описывает какую-либо часть задачи или системы, подлежащей разработке. Чтобы составить спецификацию данным методом, необходимо разделить рассматриваемую задачу на части.

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

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

Разложение системы на части выполняется по функциональному признаку. Это означает, что каждая выделяемая часть должна описывать какую-либо законченную содержательную функцию, а методы и особенности реализации не должны учитываться при разложении. 3.6.Структурный анализ (SA) (SADT - Structured Analysis and Design Technique) Систему SADT можно использовать уже при определении требований ко всей системе в целом. Она полезна также на следущем этапе при составлении спецификации и на дальнейших, где производится детализация. На этих этапах осуществляется тесное взаимодействие между уровнем проектирования логики, на котором должна быть разработана структура компонентов, и спецификацией этих компонентов.

Система SADT основана на концептуальном различии между функциональной архитектурой и архитектурой системы.

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

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

Результат этого анализа лучше всего представлять не только в виде словесного описания, но и в виде графических схем.

Использование в SADT графических методов является принципиальным моментом.