Реферат: Метод пошаговой детализации в программировании
иначе x1:=xt
все - если
все - цикл
Вывести xt, y
Конец.
Таким образом, на каждом этапе решается простая задача, что облегчает разработку алгоритма. Для решения данной задачи был использован псевдокод, но можно использовать и блок - схемы алгоритмов
Плюсы и минусы методик программирования
После того, как мы разобрались в сущности обеих методик, давайте рассмотрим, какие удобства мы получаем от их использования, и с какими проблемами сталкиваемся.
Программирование снизу вверх | Программирование сверху вниз |
Преимущества | |
Можно объединить одновременно несколько подпрограмм или модулей, так как часто одна подпрограмма более высокого уровня в проекте заменяет сразу несколько драйверов. | Серьезные ошибки с большой вероятностью отыскиваются уже на ранних стадиях проекта. |
Подпрограммы, разрабатываемые на ранней стадии работы над проектом, часто оказываются чрезвычайно полезными и в других случаях. Обычно такие низкоуровневые подпрограммы объединяют в собственные библиотеки. | На любом этапе мы можем работать всего с одной подпрограммой, а это позволяет легче отлаживать и изменять код. |
Зависимость от машинных ресурсов в целом получается меньше, так как только на поздних этапах проекта мы работаем с большим объемом кода. | Проще придерживаться единых правил при создании различных версий программы. При этом создавать полезные частные подверсии также оказывается удобно. |
Тестирование оказывается более систематичным. | |
Недостатки | |
Уже реализованные, отлаженные и протестированные модули иногда приходится отбрасывать, если в вызывающих частях программы обнаружились неустранимые ошибки, и необходимо переделывать целый блок. | Если оказывается, что модуль низкого уровня невозможно реализовать, как задумывалось, иногда приходится переделывать весь проект. |
При отладке поглощается больше машинных ресурсов |
Ни один практикующий программист, конечно, не будет жестко придерживаться одной из показанных методик. В настоящей работе мы всегда используем и те, и другие приемы.
Другие проблемы структурного программирования
Текст программы должен быть удобочитаем и понятен человеку. Существует несколько хитростей, которые помогают сделать код читабельным:
Необходимо снижать трудоемкость тестирования и отладки программы (Стоимость разработки - на 80% состоит из стоимости тестирования и отладки. Поэтому, к сожалению, именно на них и начинают экономить многие нынешние разработчики). Здесь существует только один путь: аккуратней составлять код и тщательнее планировать тестирование. В серьезных компаниях формируют отдельный отдел бета-тестирования, который занимается вылавливанием ошибок - как интерфейсных, так и внутренних.
Проблема верификации - автоматического доказательства правильности работы программы. Если программа отработала правильно на десяти тестах, это, в принципе, не значит, что на одиннадцатом она не "упадет". Но ведь нельзя проверить все возможные комбинации параметров, поэтому приходится где-то остановиться. С теоретической точки зрения вопрос о верификации чрезвычайно сложен. На практике обычно ограничиваются выбранным для данной задачи набором тестов.
Упрощение модификации программы. Любая полезная программа сейчас требует постоянного обновления, расширения функций, выпуска новых версий: на этом и живут серьезные софтверные корпорации. Лучше всего, если создавая первую версию, вы уже будете думать о следующей. Легкости изменений служат и отдельные приемы программирование: использование объектов (а сейчас компонентов), модульная структура, использование динамически подключаемых библиотек, заготовок под будущие функции и т.д.
Эффективность программы. Оптимально программа занимает минимум памяти и выполняется за минимум времени. В последнее время частенько эффективность программ подменяется "необходимыми системными требованиями" - пользователя вынуждают постоянно наращивать мощность оборудования. Но если у конкурента требования к системе окажутся ниже, а процессы станут выполняться быстрее, пользователь непременно отвернется от вашей программы.