Проектирование ПО при структурном подходе

 

Процесс проектирования сложного ПО начинается с уточнения его структуры т.е. определение структурных компонентов и связей между ними. Результат уточнения структуры Мб представлен в виде структурной или функциональной схем и описания спецификации компонентов. Структурной схемой называют схему отражающую состав и взаимодействие по управлению частей разрабатываемого ПО. Структурную схему разрабатывают для каждой программы входящей в пакет программ, а список программ пакетов определяют исходя из задач описанных в ТЗ. Самый простой вид ПО – это программа, которая в качестве структурных компонентов включает подпрограммы или библиотеки. Разработку структурной схемы программы выполняют методом пошаговой детализации. Функциональная схема – схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных потоков, указания использования файлов и устройств. Для изображения функциональных схем используются специальные обозначения установленные стандартом ГОСТ 19.71-90. Функциональные схемы более информативны, чем структурные. Все компоненты структурных и функциональных схем дБ описаны.

Пример программного комплекса:

Пример структурной схемы программного комплекса

 

Пример структурной схемы программной системы

 

Пример функциональной схемы комплекса программ

3

Функциональная схема программы системы.

 

Использование метода пошаговой детализации для проектирования структуры ПО. Метод пошаговой детализации реализуется нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг включает разложение функций на подфункции. Процесс продолжается до тех пор пока не доходит до функций алгоритм решения которых очевидный. При декомпозиции программ методом пошаговой детализации необходимо придерживаться следующих рекомендаций:

1. не отделять операции инициализации и завершения от соответствующей обработки, т.к. модули инициализации имеют плохую связанность и сильное сцепление по управлению.

2. не проектировать слишком специализированных и слишком универсальных модулей. Проектирование слишком специализированных модулей увеличивает их количество, а проектирование универсальных модулей повышает их сложность

3. избегать дублирование действий в различных модулях. Целесообразнее выносить их в отдельные модули

4. группировать сообщения об ошибках в один модуль.

 

Пример: разработать алгоритм программы построения графиков функций одной переменной на заданном интервале изменения аргумента от х1 до х2, при условии непрерывности функции на всём интервале определения.

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