Глухова Л.А. Технологии разработки программного обеспечения

Подождите немного. Документ загружается.

обрабатывает пакеты некоторых групп записей. Пакет состоит из групп

записей, каждая группа сопровождается управляющей записью, имеет

заголовок и окончание.

Первый этап пошагового уточнения.

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

программы.

{Программа обработки пакетов записей. Разработчик Иванов И.И.}

{Заголовок программы}

Второй этап пошагового уточнения.

Сохраняются комментарии предыдущего этапа и добавляются

комментарии текущего этапа.

{Программа обработки пакетов записей. Разработчик Иванов И.И.}

{Заголовок программы}

Program {Обработка пакетов}

{Сортировка групп по управляющим записям}

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

групп с неправильными управляющими записями и их обработка} {*}

EndРrogram.

Третий этап пошагового уточнения.

Дальнейшая детализация программы. Детализация фрагмента *.

Сохраняются комментарии предыдущих этапов и добавляются комментарии

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

управляющих конструкций структурного программирования.

{Программа обработки пакетов записей. Разработчик Иванов И.И.}

{Заголовок программы}

Program {Обработка пакетов}

{Сортировка групп по управляющим записям}

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

групп с неправильными управляющими записями и их обработка}

{Взятие первой группы}

While {не конец входного файла} Do

{Взятие правильной управляющей записи}

{Обработка группы записей}

End

{Обработка групп с неправильной управляющей записью}

EndРrogram.

Процесс продолжается до принятия решения о прекращении дальнейшей

детализации. В этом случае все действия, записанные в последней программе в

виде комментариев, которые не были реализованы, необходимо оформить в

виде подпрограмм.

4.2.4. Анализ сообщений

Анализ сообщений является второй из стратегий, реализующих метод

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

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

Анализ сообщений основывается на анализе потока данных,

обрабатываемых программой.

Рисунок 4.1 иллюстрирует потоки информации и обрабатывающие их

процессы для программы обработки пакетов записей [12], рассмотренной в пп.

4.2.2, 4.2.3 (см. примеры 4.1, 4.2).

Рисунок 4.1 – Диаграмма потоков данных для программы обработки пакетов

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

содержит непреобразованные входные данные, а последний только выходную

информацию. Границы, разделяющие эти потоки, показаны штриховыми

линиями (см. рисунок 4.1). Они делят диаграмму на три части.

Неправильные

пакеты

Входные

данные

Проверка

пакетов

Печать

ошибок

Правильные

пакеты

Обработка

пакетов

Результаты

Проверка

результа-

тов

Печать

ошибок

Запоминание

правильных

результатов

Сообщения

об ошибках

Неправильные

результаты

Правильные

результаты

Данные, подлежащие обработке с помощью процесса «Обработка

пакетов», могут не включать всю входную информацию, но это еще часть

входных данных. Процесс «Обработка пакетов» может включать кодирование,

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

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

отредактированные, возможно, неверные данные, но это уже выходные данные.

Три части программы, соответствующие трем потокам данных, принято

называть соответственно истоком, преобразователем и стоком.

Преобразователь — это основная часть программы, исток выполняет

функцию управления входным потоком данных, сток выполняет функцию

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

Рисунок 4.2 представляет диаграмму разбиения программы на исток –

преобразователь – сток. Линии на диаграмме показывают потоки передачи

данных между процессами.

Рисунок 4.2 – Диаграмма разбиения любой программы

на исток-преобразователь-сток

Рисунок 4.3 содержит соответствующую схему иерархии модулей

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

модулями, а также изображают отношения типа вызывающий–вызываемый.

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

может быть реализован в зависимости от назначения, сложности и размера как

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

программы.

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

использовании метода разбиения на исток – преобразователь – сток на

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

получаются модули нижнего уровня.

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

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

сток, модуля-преобразователя – преобразователь, модуля-истока – исток.

Вызывающий модуль – это главный сток для модуля-истока и главный исток

для модуля-стока.

Исток

Преобразователь Сток

Рисунок 4.3 – Схема иерархии модулей программы

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

осуществляется на уровне детализации данных для модулей истока и стока.

Рисунок 4.4 представляет иерархическую структуру модулей для первого

уровня декомпозиции программы обработки пакетов, рисунок 4.5 – для второго

уровня декомпозиции.

Рисунок 4.4 – Анализ сообщений

при проектировании программы обработки пакетов

(декомпозиция первого уровня)

На данных рисунках приняты следующие обозначения:

1) чтение правильного пакета (исток)

2) обработка пакетов (преобразователь)

3) запоминание правильных результатов (сток)

4) чтение пакета (исток модуля-истока 1);

5) проверка пакета (преобразователь модуля-истока 1);

6) запоминание неправильного пакета (сток модуля-истока 1);

7) чтение записи (исток модуля-преобразователя 2);

8) обработка записи (преобразователь модуля-преобразователя 2);

9) проверка результатов (преобразователь модуля-стока 3);

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

Управление

А В С

Обработка

пакетов

Каждый модуль программы при информационном обмене использует

определенную часть данных. Однако в иерархической структуре программы

информационные связи между модулями не отражены. Поэтому описание

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

показывающую передачу данных между различными модулями.

Рисунок 4.5 – Анализ сообщений

при проектировании программы обработки пакетов

(расширенная декомпозиция)

В этой таблице должны быть определены все способы информационного

обмена, задаваемые как при помощи формальных параметров, так и с помощью

глобальных переменных.

Таблица 4.1 представляет информационные связи между модулями для

программы обработки пакетов.

Таблица 4.1 – Таблица межмодульных связей

Модуль Вход Выход

1 —

Правильный пакет

Конец файла

2 Правильный пакет Результаты пакета

3 Результаты пакета —

4 —

Данные пакета

Конец файла

Обработка

пакетов

4 5 6 7 8 9 10

Модуль Вход Выход

5 Данные пакета

Правильный пакет

Неправильный пакет

6 Неправильный пакет —

7 Правильный пакет Правильная запись

8 Правильная запись Результаты записи

9 Результаты записи

Правильные результаты

Неправильные результаты

10 Правильные результаты —

Таблица 4.1 отражает те данные, которые передаются каждому модулю в

момент его вызова. Элементы данных, используемые главным модулем,

изображены как выходные для вызываемых им модулей. Выходные данные

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

Поэтому модуль-исток имеет выходные данные, сток – входные данные,

преобразователь – и те, и другие.

Стратегия анализа сообщений включает организацию взаимодействия

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

4.3. Метод восходящего проектирования

При использовании метода восходящего проектирования в первую

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

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

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

определения функций более высокого уровня. Эти функции используются для

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

завершена разработка всей программы.

В чистом виде метод восходящего проектирования используется крайне

редко, так как он имеет существенные недостатки. Основной его недостаток -

программисты начинают разработку программы с несущественных,

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

Однако, иногда использование метода восходящего проектирования

целесообразно. Это происходит в следующих случаях:

А) существуют разработанные прикладные программы, которые могут

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

программы;

Б) если заранее известно, что некоторые простые или стандартные

модули потребуются нескольким различным частям программы (например,

подпрограмма анализа ошибок, ввода-вывода и т.п.).

Чаще используется сочетание методов нисходящего и восходящего

проектирования. Такое сочетание возможно различными способами. Ниже

рассмотрены два из них [13].

Первый способ сочетания.

Находятся ключевые (наиболее важные) модули промежуточных

уровней. Затем проектирование ведется нисходящим и восходящим методами

одновременно (рисунок 4.6).

Рисунок 4.6 – Одновременное проектирование нисходящим и восходящим

методами

Второй способ сочетания.

Проектируются модули нижнего уровня (те, которые необходимо

спроектировать заранее). Затем программа проектируется одновременно

нисходящим и восходящим методами (рисунок 4.7).

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

является согласование интерфейса между верхними и нижними уровнями

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

(программист) должен обладать достаточно высокой квалификацией, чтобы не

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

Это является недостатком второго способа совмещения.

Восходящее проектирование

программы на базе ключевых

модулей

Нисходящее

проектирование

ключевых модулей

Ключевые модули

промежуточных уровней

(разрабатываются вначале)

Рисунок 4.7 – Одновременное проектирование нисходящим и восходящим

методами

4.4. Метод иерархического

проектирования модулей (метод

Джексона)

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

методами нисходящего и восходящего проектирования, относится метод

расширения ядра. Данный метод отличается от метода нисходящего

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

множества вспомогательных функций, а не определению функции всей

программы в целом.

Для получения вспомогательных функций существует два подхода [12].

Первый подход основан на методах проектирования структур данных,

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

разработан Джексоном.

Второй подход основан на определении областей хранения данных с

последующим анализом связанных с ними функций. Данный подход

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

Парнасом.

В данном учебном пособии рассмотрен метод Джексона, реализующий

первый подход. Метод наиболее эффективен в случае высокой степени

Нисходящее

проектирование

Восходящее

проектирование

Модули нижнего

уровня, проектируе-

мые в 1-ю очередь

Интерфейс между верхним и нижним уровнями программы

структуризации данных (например, в задачах, связанных с экономической

отчетностью).

Метод разработан в 1975 г. А.Джексоном.

Метод базируется на исходном положении, состоящем в том, что

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

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

формирования структуры программы.

4.4.1. Основные конструкции построения

структур данных

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

данных и структур программ единым набором основных конструкций [16].

Существует четыре основных конструкции данных.

1. Конструкция последовательности данных.

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

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

большой компонент данных (рисунок 4.8).

На данном рисунке компоненты В, С, D, E объединяются в указанном

порядке и образуют последовательность А.

Таким образом, в последовательности должно быть не менее двух

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

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

Рисунок 4.9 представляет пример последовательности данных – запись R,

состоящая из трех последовательных частей – поля Н заголовка, поля D данных

и поля Т завершителя.

Рисунок 4.8 – Конструкция последовательности данных

EDCB

Рисунок 4.9 – Пример последовательности данных

2. Конструкция выбора данных.

Конструкцией выбора данных (выбором данных) называется конструкция

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

избираемых подкомпонентов.

Рисунок 4.10 иллюстрирует выбор S, который сводится либо к

подкомпоненту Р, либо Q, либо R.

Рисунок 4.10 – Конструкция выбора данных

Внешне конструкция выбора данных отличается от последовательности

наличием символа «О» в верхнем правом углу каждого из выбираемых

подкомпонентов.

Таким образом, в выборе должно быть не менее двух подкомпонентов.

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

либо отсутствует, то такой выбор некорректно изобразить так, как

иллюстрирует рисунок 4.11. Данный выбор должен быть представлен так, как

изображает рисунок 4.12.

Запись R

Заголовок Н Данные D

Завершитель