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

Проектирование программы включает в себя три этапа:

1) декомпозиция задачи (программы);

2) разработка структуры данных программы;

3) алгоритмизация программы.

Рассмотрим реализацию этих этапов.

Декомпозиция общей задачи

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

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

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

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

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

Для успешной декомпозиции общей задачи процесс разбиения должен подчиняться следующим правилам:

на каждом этапе подзадача некоторого уровня должна разбиваться не более чем на 2 7 подзадач следующего уровня;

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

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

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

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

Рис. 3.6. Традиционные связи подчинения между подзадачами:

а) иерархические; б) временные

Это усложняет процесс проектирования программы, так как в этом случае:

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

2) остаются в тени данные, которыми обмениваются подзадачи в процессе решения общей задачи.

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

Для повышения наглядности при декомпозиции задачи рекомендуется использовать графические схемы, приведенные на рис. 3.7. В этих схемах прямоугольниками обозначены входные и выходные данные, которыми оперируют некоторые подзадачи, а окружностями  вычислительные процессы по преобразованию входных данных в выходные, реализуемые ими [9,10].

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

Схема задачи после первого этапа декомпозиции представлена на рис. 3.7,б. Общая задача разбита на две подзадачи. Взаимодействие между подзадачами осуществляется через общие области данных для обмена, называемые наборами данных. Набор данных представляет собой некоторую область памяти. Информация в нем может быть представлена самым различным образом. Эти данные обрабатываются вычислительными процессами последующих подзадач в соответствии с заложенными в них алгоритмами. Для успешного проектирования вычислительных процессов необходимо четко представлять данные, которыми они оперируют. Отсюда становится очевидной знаменитая формула Н.Вирта "Программа = Алгоритмы + Структуры данных". Однако определение структур данных должно предшествовать разработке алгоритмов, так как необходимо иметь некоторые объекты, прежде чем оперировать ими.

Рис. 3.7. Представление процесса декомпозиции задачи:

а) исходное представление задачи;

б) представление первого этапа декомпозиции

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

Рис. 3.8. Обобщенная схема процесса решения задачи в МПС

Подзадача "Рабочий процесс" (РП) реализует основные функции МПС, а подзадача "Контрольный процесс" (КП) обеспечивает контроль ее ресурсов. При этом контролю могут подвергаться как функциональные ошибки, так и аппаратные ресурсы системы.

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

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

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

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

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

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

Рис. 3.9. Обобщенная схема контрольного процесса

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

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

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

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

В качестве порога для фиксации ошибки могут использоваться следующие критерии:

1) плотность потока ошибок, определяемая частотой их появления во времени;

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

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

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

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

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