
- •1 Программное обеспечение сутп
- •2 Структура интегрированной системы автоматизированного управления.
- •4 Основные принципы тестирования и верификации программ
- •5 Физическая и логическая структуры данных
- •6 Общая концепция и типы структур распределенных баз данных
- •7 Проектирование по.
- •8 Эталонная модель взаимодействия открыты систем .
- •9 Основы концептуального проектирования бд
- •10 Нисходящая и восходящая технологии программирования.
- •11 Функции администратора по су тп.
- •12 Жизненный цикл по
- •13 Статические и динамические структуры данных, их особенности
10 Нисходящая и восходящая технологии программирования.
Методы регламентирующие высокий профессиональный уровень написания программ независимо зли почти независимо от языка, операционной системы ЭВМ и решаемой задачи:
система методов, способов и приемов разработки и отладки программ;
совокупность организационно-административных и инженерно-технических средств поддерживающих создание, документирования, распространения и сопровождения программного продукта.
Для описания этих средств применяются графы, диаграммы и т.п. Унифицируется и стандартизируются административно-управленческие приемы и средства, коммуникатируются документация. Регламентируется этапность жизненного цикла программного продукта и применительно к этим этапам, разрабатывается нормативы производительного труда, надежность и качества изделий.
Основой технологии программирования служит модульность программы главной чертой которой является:
» стандартизация;
» паспортизация модулей;
» межмодульный интерфейс;
» унификация.
Технология программирования базируется на поэтапном построение программ, т. е. нисходящее и восходящее проектирование. Необходимость перехода к нисходящему проектированию при создании больших систем программного обеспечения стала очевидной в результате неудачных попыток по созданию программ из методов исходящего проектирования. Метод восходящего проектирования заключается в том, что вначале разрабатывается отдельные модули на языке низкого уровня, а затем они объединяются в систему. Поэтому недостатки проекта часто обнаруживаются только при отладке программного комплекса, т. е. оказывается, что множество модулей было написано и проверено только для того, чтобы быть затем забракованными. В противоположность этому при нисходящем проектировании сначала пишут и проверяются управляющие программы, а функциональные модули добавляют в процессе разработки системы. Таким образом, создание системы происходит путем её расширения уровень за уровнем с проверкой и объединением модулей в процессе программирования, а не после её окончания. На каждом уровне процесса проектирования отрабатываются программы обслуживания и определяются данные.
Нисходящее проектирование систем программного обеспечения обычно начинается с логического проектирования, обеспечивающего согласованную работу нескольких модулей, которым необходим доступ к совместно используемым данным.
Легко заметить, что преимущество нисходящего проектирования по сравнению с восходящим есть преимущество процесса при наличии обратной связи по сравнению с процессом без обратной связи. При восходящем проектировании программы не проверяются как составная часть системы до окончания разработки. При нисходящем же проектирование их проверяют сразу, в контуре системы. Если допущены ошибки в проектирование или в программирование, нисходящее проектирование позволяет обнаружить их на ранних этапах, когда программа еще находиться у разработчика. Восходящее же проектирование приводит к ошибкам, которые могут быть обнаружены только при комплексной отладки, когда разработчик модуля уже переключился на другую работу.
Разрабатывать программы с использованием метода нисходящего проектирования сложнее, чем применяя метод восходящего проектирования, но затраченные усилия окупаются на этапе объединения и отладки. Реализация метода нисходящего проектирования дает возможность предвидеть, что будет представлять собой система не только по окончанию разработки, но и на каждой промежуточной стадии. Продемонстрируем это на примере строительства поста. При проектирование моста на бумаге сначала изображают ферму, затем другие детали моста, в том числе опоры. Но для строительства моста нужен конструкторский план размещения каждой фермы и их соединений с помощью опор.
Разработка системы программного обеспечения методом восходящего проектирования напоминает проектирование моста на бумаге. Нужен только окончательный проект, и тогда можно надеяться, что и без «инструкторского плана все пойдёт гладко. К сожалению, людям, в том числе и конструкторам, свойственно ошибаться, поэтому реализация этого подхода сопровождается рядом трудностей.