Тема 3. Нисходящее проектирование. 1. Суть нисх. проектир-я. Файл 681453772. С. 1 из 3 Тема 3. Нисходящее проектирование 1. Суть нисходящего проектирования. Материал: файл tema_3vopr1.doc 2. Пример нисходящей разработки. Материал: файлы tema_3vopr2.doc, plan_nish_otl.doc, primer2.doc 3. Условия успешного применения и оценка нисходящего подхода. Материал: файл tema_3vopr3&4.doc 4. Восходящий подход как «традиционная» альтернатива нисходящему. Соотношение подходов Материал, общий для тем 3 и 4: схемы нисходящей и восходящей отладки – файлы nishotl.doc, voshotl.doc; принципы тестирования - файл test_bas.doc (выдавались на лабораторных работах). 1. Суть нисходящего проектирования В сокращенном виде материал по нисходящей разработке был представлен в лабораторной работе 1. Нисходящая разработка как двухкомпонентный процесс поуровневого проектирования и отладки Нисходящая разработка представляет собой поэтапный процесс, результатом которого на каждом уровне разработки является отлаженная и оттестированная программа этого уровня, т.е., возможно, с наличием нераскрытых абстракций. Отделить проектирование от отладки в процессе разработки нельзя. Однако такое разделение неизбежно при описании разработки, поскольку описание являет собой вещь статическую. Поэтому в данной теме делается акцент на проектировании, а в следующей – на нисходящей отладке разрабатываемого программного продукта. Тем не менее связь этих аспектов просматривается постоянно и справочный материал по разработке и отладке является практически полностью общим для обеих тем. Общая характеристика нисходящего проектирования Методика нисходящей, или пошаговой разработки программ считается самой сильной формализацией в области проектирования алгоритмов начиная с 70-х годов. Именно поэтому нисходящий подход представляет собой один из важнейших принципов современной методологии разработки программ, независимо от используемой парадигмы программирования и расстановки акцентов на тех или иных этапах жизненного цикла. Предлагаемый подход может рассматриваться как синтез классического нисходящего подхода и более поздней методики потоков работ (Workflow methodology). Суть этого подхода, как и суть любого процесса проектирования, на первый взгляд проста: разбиение задачи на подзадачи до получения подзадач, реализуемых имеющимися в наличии исполнителя средствами. Однако эта простота обманчива, и в действительности для овладения описываемым подходом требуются хорошо отработанные навыки систематического мышления и взгляд на программирование как на интеллектуальную дисциплину, направленную на решение задач, а не на комбинирование операторов конкретного языка. Поэтому такой подход требует серьезной и тщательной работы. В рамках учебного процесса, не позволяющего конструктивно (т.е. доводя решение до программного продукта) рассматривать достаточно сложные реальные задачи, требующие прежде всего анализа и уточнения постановки, нисходящая разработка лучше всего иллюстрируется на процессе разработки алгоритмов достаточно хорошо сформулированных задач. Поэтому ниже изложение ведется именно в таком аспекте. Собственно нисходящая методика принципиально не предполагает использования какого-либо конкретного языка программирования и наилучшим образом реализуется на основе средств проектирования алгоритмов, основанных на структурном подходе. Такими средствами являются, например, язык проектирования программ PDL (см. ссылку на кн. Лингера и др. в теме 2) и менее жесткий язык псевдокод, рассмотренный в теме 2. Очевидно, что используемый при нисходящей разработке язык проектирования должен содержать средства описания подзадач и их связи с задачами более высокого уровня. Тема 3. Нисходящее проектирование. 1. Суть нисх. проектир-я. Файл 681453772. С. 2 из 3 Общая схема Суть нисходящего проектирования, или проектирования сверху вниз, состоит в пошаговой декомпозиции (разложении) задачи на точно определенные подзадачи. К счастью или к сожалению, четких формальных критериев такой декомпозиции не существует, поэтому процесс, особенно для нестандартных задач, является в большой степени творческим и требует навыка и опыта. Парадоксальным на первый взгляд, но наиболее конструктивным критерием выделения подзадач является такой: каждая подзадача должна быть сформулирована кратко, точно и емко, т.е. должно быть ясно, что дано и что требуется найти, и при этом нет необходимости прибегать к описанию мелких действий. Примеры корректных формулировок: «Найти сумму..», «Проверить наличие элементов …» и т.д. Процесс нисходящей разработки является иерархическим. Схема его приведена на рис. 3.1. 0-й уровень (проблемный, абстрактный): исходная задача Исходная задача A0 1-й уровень: подзадачи задач 0-го уровня Подзадача A0.1 Подзадача A 0.2 ...... Подзадача A 0.k 2-й уровень: подзадачи задач 1-го уровня Подзадача A 0.2.1 Подзадача A 0.2.2 ...... Подзадача A 0.2.р .................. Дальнейшее разбиение на подзадачи ...... .................. Уровень подзадач, реализуемых в языке программирования (исполнительный уровень) ...... Рис. 3.1. Общая схема нисходящего проектирования Смысловая сторона нисходящего проектирования состоит в следующем: на каждом уровне проектирования мы полагаем, что каждая сформулированная подзадача реализуема, и, не интересуясь деталями этой реализации, рассматриваем ее как единое обобщенное действие, называемое абстракцией. Иначе говоря, абстракция – подзадача, рассматриваемая как «черный ящик». По форме это некоторое обобщенное действие ("проверить правильность", "поиск максимума", "найти сумму"). Будем обозначать абстракции именами, начинающимися с буквы А. Назовем реализацией, или раскрытием абстракции некоторого уровня некоторый способ объединения результатов решения ее подзадач (абстракций низшего уровня). В этих терминах исходную постановку задачи можно рассматривать как абстракцию самого высокого (нулевого) уровня, а решение задачи – как пошаговую реализацию этой абстракции вплоть до исполнительного уровня. Обозначим эту абстракцию A0. Как видно из схемы, каждая подзадача некоторого уровня раскрывается на следующем, также путем разложения на подзадачи – и т.д., до получения подзадач, алгоритм решения которых можно непосредственно записать на языке исполнительного (физического) уровня. В случае проектирования алгоритмов исполнительным уровнем (операционной средой) является заданное множество возможных операций по преобразованию используемых данных. Это возможности того, кто исполняет алгоритм. Например, исполнительный уровень при решении арифметических задач вручную – множество арифметических операций, на компьютере – множество операций используемого языка или среды программировния, для алгебраических задач – законы алгебры. Если задачу решает специалист в некоторой области, то исполнительный уровень – множество методов, которыми владеет этот специалист. Тема 3. Нисходящее проектирование. 1. Суть нисх. проектир-я. Файл 681453772. С. 3 из 3 Реально прямой переход от задачи к решению возможен только для тривиальных задач; обычно число уровней много больше двух. Одним из ярких, но неосознаваемых примеров нисходящего подхода является расчет параметров электрической цепи. Здесь иcполнительный уровень – арифметические операции, выполняемые согласно нужным формулам. Но до получения этих формул исходя из заданных параметров цепи и подстановки в формулы численных данных необходимо проделать массу преобразований схем и выводов формул. Нисходящее проектирование и нисходящая отладка На любом уровне проектирования одни элементы алгоритма могут быть доведены до исполнительного уровня и закодированы, другие же представлены в виде абстракций. Нисходящая отладка представляет собой постепенный процесс отладки такого незавершенного кода программы на каждом уровне. В основе ее лежит тот факт, что любая подзадача связана с остальными только своим интерфейсом, т.е. совокупностью получаемых ею входных данных и передаваемых дальше выходных данных. Эти положения приведены в лабораторной работе 1 и подробно рассматриваются в теме 4 и примере нисходящей разработки. Здесь об этом упоминается, чтобы еще раз подчеркнуть единство процессов нисходящего проектирования и нисходящей отладки, обеспечивающее эффективность разработки в целом. Механизм процедур как адекватное средство реализации нисходящего подхода Самым мощным механизмом любого достаточно развитого конкретного языка программирования является механизм процедур. Аппарат процедур предоставляет формальные средства абстракции, т.е. формально в виде процедуры может быть оформлена любая последовательность операций с тем, чтобы впоследствии быть вызванной по имени. Однако как некоторый результат деятельности по разработке программы такая последовательность всегда несет смысловую нагрузку - решает какую-либо задачу. Таким образом, уже сам факт использования процедур в любом случае предполагает (осознанно или неосознанно, формализовано или нет) процесс нисходящего решения задачи с поэтапным выделением подзадач. Поэтому механизм процедур является адекватным средством реализации нисходящей методологии, начиная с этапа проектирования и заканчивая реализацией программы с использованием конкретной системы программирования. Резюме Процесс нисходящего проектирования есть процесс поэтапного раскрытия абстракций. Сам процесс выделения абстракций - неформальный, творческий Общих критериев его оценки нет. Составить удачный проект за один проход чаще всего нельзя. Принцип нисходящего проектирования кажется интуитивно очевидным, однако практика показывает, что реализация этой идеи весьма непроста.