5.4. Порядок разработки программного модуля

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

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

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

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

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

Шаг проверки – это ручную прогонку внутренней логики модуля до начала его отладки.

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

5.5. Структурное программирование

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

О сновными конструкциями структурного программирования являются: следование, разветвление и повторение (рис. 10).

Компонентами этих конструкций являются обобщенные операторы (узлы обработки) S, S1, S2 и условие (предикат) P. В качестве обобщенного оператора выступает либо простой оператор языка программирования (операторы присваивания, ввода, вывода, обращения к процедуре), либо фрагмент программы, также являющийся композицией основных конструкций структурного программирования. Каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход. Эти конструкции являются математическими объектами. Доказано, что для каждой неструктурированной программы можно построить функционально эквивалентную (т.е. решающую ту же задачу) структурированную программу. Для структурированных программ можно математически доказывать некоторые свойства, позволяющие обнаружить в ней отдельные ошибки.

Структурное программирование иногда называют "программированием без GO TO". Однако дело здесь не в операторе GO TO, а в его беспорядочном использовании. Часто оператор перехода (GO TO) используется для реализации структурных конструкций, что не нарушает принципов структурного программирования. Запутывают программу "неструктурные" операторы перехода, особенно переход к оператору, расположенному в тексте модуля выше (раньше) выполняемого оператора перехода. Однако попытка избежать оператора перехода в некоторых простых случаях приводит к громоздким структурированным программам, что не улучшает их ясность и обуславливает появление дополнительных ошибок. Рекомендуется избегать употребления оператора перехода всюду, где это возможно, но не ценой ясности программы.

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