Структурное программирование.
Состоит из трех частей:
1. Суть структурного программирования.
2. Нисходящая разработка.
3. Сквозной структурный контроль.
1. Суть структурного программирования
Использование небольшого набора простых управляющих структур и структур данных. Программа строится путем вложений операторов одного в другой.
Программа, написанная с использованием методов структурного программирования понятна, более надежна и облегчает сопровождение.
Структурное программирование использует 3 базовые комбинации:
1) Следование:
Последовательно выполнение операторов А и В (или групп операторов).
· А=0
А=А+5
2)
|
|
· Оператор IF. Возможно отсутствие 1 из альтернатив.
3) Цикл (повторение):
· FOR …
WHILE …
REPEAT …
Трансляторы, которые используют структурное программирование, позволяют чисто внешне структурировать текст программы:
Раньше:
Метка | Оператор | Комментарий |
2 симв. | ……………… | ……………………. |
Сейчас:
DO WHILE…
DO WHILE…
FOR …
…
ENDDO
ENDDO
Проектирование сверху – вниз. Меньше использовать оператор GOTO метка. Необходимо наличие одного входа и одного выхода к одному и тому же оператору (группе операторов).
2. Нисходящая разработка.
Это проектирование модулей сверху – вниз.
Схема иерархии разрабатывается на этапе проектирования для упрощения процесса разработки над всем программным комплексом. добавление отдельных модулей или функций. удобства корректировки.
Модуль – отдельная программная часть, выполняющая 1 функцию.
Модуль - это элемент программы.
3 похода к программированию схемы иерархии:
1. Иерархический.
В первую очередь разрабатывается главное меню ( 1 уровень), затем – 2 уровень, 3 и …
На каждом уровне после написания программы идет модульное тестирование (осуществляется программистом).
2. Операционный.
Модули разрабатываются в порядке их выполнения пользователем.
1. Главное меню.
2. Создание БД.
3. Файл 1, ф.2, … (из 3 уровня).
4. Просмотр БД.
5. Логич..
6. Ф.1, ….
7. Физич..
8. Ф.1, … и т. д.
Преимущества подхода:
Минимизируются трудности, вызванные зависимостью по данным, т.е программируются модули, которые порождают данные для последующих модулей.
Недостатки:
1. Может получиться очередность в программировании модулей.
2. Большое число программ – заглушек.
3. Комбинированный.
Учитываются:
1) Зависимости по данным.
2) Доступные ресурсы.
3) Требования в выдаче результатов.
4) Необходимость в обеспечении готовности вспомогательных модулей.
5) Сложность самого модуля.
6) Обработка аварийных или исключительных (неправильно введенных данных) ситуаций.
1. Главное меню.
2. Создание БД.
3. Файл 1, ф.2, ….
4. Корректировка. (7)
5. Добавление. (4)
6. Удаление. (5)
7. Изменение (редактирование). (6)
Преимущества подхода:
1. Удовлетворяют всем 6 вышеупомянутым факторам.
2. На сложные модули может уделять больше времени.
3. Сквозной структурный контроль.
Это средство, которое облегчает управление проектом. является техническим средством и используется людьми, занятыми непосредственно в проекте.
Контрольные встречи (сессии) проводятся руководителем проекта или главным программистом, его замом + исполнитель работы (контролируемое лицо) + иногда лицо со стороны заказчика.
Чем чаще сессии, тем меньше ошибок в программном продукте, упрощается процесс тестирования, ускоряется процесс разработки программного продукта.
Элементы, которые проверяются на сессии.
Этапы проектирования | Что проверяется | Наиболее вероятные недостатки |
1. Определение требований | Планы программного продукта. сроки. сфера применения продукта | Улучшения в различных функциях проекта. нереальные сроки использования каждого модуля. узость использования программного продукта. неудобство пользование потребителем. |
2. Определение спецификации | Спецификация на систему. постановка задачи. тесты контроля. | Неполная, нечеткая спецификация. нереальная постановка задачи. входные данные не равны выходным. |
3. Проектирование. | Функциональные спецификации. проектирование программы – схема иерархии. обработка аварийных ситуаций. требования. | Неполная спецификация. недостаточно детализирована спецификация. плохо определены функции => нечеткая схема иерархии. плохо отслежена обработка аварийных ситуаций. несоответствие требованиям. |
4. Программирование. | План порядка разработки модулей. план их тестирования. тесты. | Зависимость по данным. несоответствие требованиям. недостаточно полный набор тестов. |
5. Тестирование. | Взаимодействие модулей. документация. если нужно – код программы (текст программы). | Отклонения от общего проекта. могут появиться ненужные модули. проверяется логика программы (если нужно), расхождения документации с программным продуктом. |
6. Эксплуатация. | Окончательно документация. Весь программный продукт тестируется в целом. соответствие программного продукта со спецификацией. | Изменения в спецификации. нечеткая документация. |
Дата добавления: 2015-08-14; просмотров: 1765;