Метод пошаговой детализации.

Функциональная схема ПО.

Структурная схема ПО.

Тема 2.2. Методы проектирования структуры ПО

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

Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.

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

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

Более полное представление о проектируемом программном обеспече­нии с точки зрения взаимодействия его компонентов между собой и с внеш­ней средой дает функциональная схема.

Это схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функцио­нальных схем используют специальные обозначения, установленные ГОСТ 19.701-90 (табл. 5.1).

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

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

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

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

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

Кроме этого, целесообразно придерживаться следующих рекомендаций:

• не отделять операции инициализации и завершения от соответствую­щей обработки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению);

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

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

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

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