Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
6 Программное обеспечение СУТП готов.doc
Скачиваний:
1
Добавлен:
01.04.2025
Размер:
531.46 Кб
Скачать

10 Нисходящая и восходящая технологии программирования.

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

  • система методов, способов и приемов разработки и отладки программ;

  • совокупность организационно-административных и инженерно-технических средств поддерживающих создание, документирования, распространения и сопровождения программного продукта.

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

Основой технологии программирования служит модульность программы главной чертой которой является:

» стандартизация;

» паспортизация модулей;

» межмодульный интерфейс;

» унификация.

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

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

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

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

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