Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции по САПР.doc
Скачиваний:
272
Добавлен:
02.05.2014
Размер:
3.88 Mб
Скачать

Глава 8

ПРОГРАММИРОВАНИЕ

8.1 Введение

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

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

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

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

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

1. Прежде всего следует считывать управляющий файл.

2. Запись читается сразу по завершении обработки предыдущей записи.

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

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

Эти правила положены в основу принципа предварительного считывания.

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

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

В качестве альтернативы были предложены так называемые спецификационные языки (псевдокоды). Для построения типовых логических конструкций применяются ключевые слова: ВЫБОР, ВАРИАНТ, КОНЕЦ ВЫБОРА, ЕСЛИ, ТО, ИНАЧЕ, КОНЕЦ ЕСЛИ, ПОВТОРЯТЬ ПОКА, КОНЕЦ ПОВТОРЕНИЙ. Для описания действий, выполняемых программой, используются предложения естественного языка. Большое значение имеют пробелы, улучшающие восприятие текста.

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

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

ОТКРЫТЬ ФАЙЛЫ

ЧИТАТЬ ОСНОВНОЙ ФАЙЛ

ОБРАБОТАТЬ ЗАГОЛОВОК ФАЙЛА

ВЫПОЛНЯТЬ ПОКА ЕСТЬ РАЙОНЫ

ОБРАБОТАТЬ ЗАГОЛОВОК РАЙОНА

ЧИТАТЬ ОСНОВНОЙ ФАЙЛ

ВЫПОЛНЯТЬ ПОКА ЕСТЬ ЕЩЕ ДЕТАЛЬНЫЕ ДАННЫЕ

ЕСЛИ ПРЕДПРИЯТИЕ

ОБРАБОТАТЬ ДАННЫЕ ПО ПРЕДПРИЯТИЮ

КОНЕЦ ЕСЛИ

КОНЕЦВЫП

ВЫВЕСТИ СТРОКУ ИТОГОВ ПО РАЙОНУ

КОНЕЦВЫП

ОБРАБОТАТЬ ИТОГОВЫЕ ДАННЫЕ ПО ФАЙЛУ

ВЫВЕСТИ СТРОКУ ОБЩИХ ИТОГОВ

ЗАКРЫТЬ ФАЙЛЫ

Рис. 8.6 Псевдокод программы выборки из основного файла.

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

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

8.3 Структура программы

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

  • точность и достаточность детлизации имеющихся спецификаций;

  • наличие источников всех выходных данных;

  • принципиальная возможность решения прикладной программ

  • уровень сложности будущей программы

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

Прежде всего нужно выписать все выходные данные и их источники

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

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

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

  • будет невозможно получить выходные данные в требуемой последовательности;

  • для принятия решений в ходе обработки придется запоминать множество зписей;

  • составленная по спецификации программа окажется слишком большой и сложной.

    1. Логическое проектирование программ

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

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

  2. Выбор управляющего файла

  3. Уточнение струкутуры управляющего файла в соответсивии с требованиями к обработке данных.

  4. Выявление соответствия между файлами

  5. Разработка укрупненной структуры программы

  6. Расширение (раскрытие содержания) модулей с помощью псевдокода начиная с верхнего уровня логической струкутры и самой сложной ее ветви

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

  8. Оценка полученных результатов

Рис. 8.14 Логическое проектирование программы

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

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

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

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

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

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

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

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

  • Можно ли сформулировать назначение модуля одним предложеним? Если это так, то скорее всего, его логика достаточно прорста.

  • Предназначен ли модуль для обработки данных?

  • Соответствуют ли процедуры инициализации и завершения своему прямому назначению и не модифицируют ли они вместо этого какие-либо физические записи?

    1. Уточнение прoекта

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

  1. Проверка приемлемости размера модулей

  2. Объединение или разделение модулей

  3. Выявление общих функций и выделение самостятельных модулей

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

  5. Критический анализ внесенных уточнений

Рис. 8.17. Последовательность операций при уточнении проекта

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

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

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

По завершении всех уточнений выполняется критический анализ скорректированного проекта.

    1. Оптимизация программы

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

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

Стараться не проводить оптимизацию

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

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

    1. Физическое проектирование программ

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

  • действующие в организации нормы на максимальный размер модулей;

  • производительность технических средств;

  • возможность применения общих подпрограмм;

  • возможность написания самых «ответственных» модулей на языке более низкого уровня;

  • простота тестирования и отладки программы;

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

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

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

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

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

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

  1. Объединение взаимосвязанных логических модулей в физические модули

  2. Разработка иерархической схемы физических модулей

  3. Спецификация интерфейсов между физическими модулями

  4. Критический анализ результатов

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

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

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

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

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

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

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

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

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

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

8.12 Тестирование программы

При тестировании программы проверяется работает ли программа т все ее ветви в соответствии со своей спецификацией.

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

Формирование единого нбора тестовых данных для системы гарантирует их достоверность и уменьшает трудоемкость тестирования.

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

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

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

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

Один из вариантов этого метода состоит в тестировании одной полной ветви программы. Первой проверяется (с помощью заглушек) управляющая логика.

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

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

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

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

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

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

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

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

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

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

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

8.13. Проектирование программ для систем реального времени

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

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

Различают:

  • диалоговые, пзвляющие осуществлять ввод и вывод данных на терминал аналогично чтению и размещению записей в файле;

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

Особеннсти разработки.

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

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

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

8.14. Разработка программ в диалоговом режиме

Конироль изменений. Можно добиться точной регистрации изменений в программах, для чего необходимо поддерживать последоватещльные версии программ, в которых тражается их «история»: сведения о датах, авторах и причинах изменений. Точно так же можно следить за изменением тестовых файлов.

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

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

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