Нисходящее проектирование

Cтраница 3

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

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

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

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

Общая схема работы программы перевода. [35]

Ниже приводится несколько первых шагов нисходящего проектирования вполне реальной и достаточно сложной задачи. [36]

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

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

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

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

Как видно из примеров, при нисходящем проектировании производится разбиение программы или ее частей на функционально независимые фрагменты я программирование их отдельно друг от друга. Тем самым достигается независимость фрагментов программы и в крупном - для случая. [41]

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

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

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

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

Страницы: 1 2 3 4