Структурное проектирование сложных программных средств При разработке структуры программного средства

Методология структурного анализа и предварительного структурного проектирования ПС начинается с общего обзора функций системы. Далее функции должны детализироваться сверху вниз в виде иерархической структуры таким образом, чтобы процедуры сбора, хранения и переработки информации, рассматриваемые сначала как нечто единое целое, расчленялись на отдельные элементы данных, компонентов и действия, совершаемые над этими данными. Структурный анализ, исходя из функционального описания системы в целом, позволяет разделить ее на функциональные части, выделить функциональные описания отдельных частей, исследовать в них информационные потоки и формализовать структуры данных.
Разделение общей задачи системы и программного средства на компоненты — это использование принципа здравого смысла, который должен быть применен в системной разработке крупного ПС для преодоления свойственной ему сложности. Очень часто многие решения прочно взаимосвязаны и взаимозависимы. Когда различные проектные решения прочно взаимосвязаны, то бывает полезно, чтобы всеми ими сразу занимались в одно и то же время одни и те же люди, но на практике это обычно невозможно. Единственный способ справиться со сложностью проекта — разделить задачи. Прежде всего, необходимо пытаться изолировать функции, которые менее всего связаны с другими. Затем рассматривать раздельно функции, учитывая имеющие отношения между собой и детали связанных проблем.
Спецификация требований к предварительной архитектуре комплекса программ формируется в процессе детализации и уточнения спецификации требований к характеристикам ПС в результате проверки последних на непротиворечивость и полноту. Задача спецификации требований архитектуры состоит в том, чтобы представить достаточно ясное и удобное общее описание внешнего поведения системы и свойств, а также ее внутренней структуры и механизмов функционирования. В общем случае формализованные методы, применяемые при специфицировании системной архитектуры ПС, должны обеспечивать:
эффективные и удобные средства описания свойств и особенностей структуры создаваемой системы — нотации описания;
методику последовательного, итерационного уточнения спецификаций требований и проектных спецификаций компонентов, позволяющую проверять их корректность;
средства и методику для возможности прослеживания реализации требований и тестирования, позволяющего устанавливать соответствие свойств реализуемого ПС и компонентов его спецификациям.
Описания проектных решений должны содержать первичные спецификации крупных функциональных компонентов ПС, подлежащих разработке в детальном проекте создаваемой системы, и спецификаций используемых готовых компонентов, состав которых определяется при декомпозиции общей структуры системы. В требованиях спецификации к системной архитектуре комплекса программ должно обеспечиваться:
соответствие функций и структуры ПС аппаратной и операционной среде, их ресурсам и интерфейсам;
совместимость ПС с другими системами по источникам и потребителям информации;
соответствие стандартам структурного построения и интерфейсов комплекса программ, функциональных компонентов и модулей;
предварительная организация информационного обеспечения и структура базы данных;
состав, структура и способы обмена данными между функциональными компонентами и внешней средой ПС;
временной регламент и предварительные характеристики процессов реализации функций, интенсивность и объемы потоков информации базы данных;
контроль, хранение, обновление, защита и восстановление программ и данных;
стандартизированные, предварительные требования к составу и содержанию технологической документации.
Таким образом, для обеспечения эффективного управления разработкой программ необходимо при системном проектировании стандартизировать и соблюдать ряд принципов архитектурного построения ПС, Эти принципы могут иметь особенности для проектов ПС в различных проблемно-ориентированных областях. Однако их стандартизация обеспечивает значительный эффект в снижении трудоемкости и длительности последующей детальной разработки программного продукта и версий. Частичная потеря гибкости архитектуры ПС, некоторое возрастание ресурсов, необходимых для реализации этих принципов, обычно полностью компенсируются повышением управляемости процесса разработки, а также качества ПС.
Структурное проектирование программных средств основано на модульном принципе. Многоуровневое, иерархическое построение сложных программных комплексов позволяет ограничивать и локализовать на каждом из уровней соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные и информационные модули (модули данных). Эти компоненты объединяются в группы программ определенного функционального назначения с автономной целевой задачей. Несколько групп функциональных программ образуют комплекс программ. В особо сложных случаях возможно создание программного средства из нескольких взаимодействующих комплексов. Всем иерархическим системам (в частности, ПС) присущ ряд общих свойств, важнейшими из которых являются:
вертикальная соподчиненность, заключающаяся в последовательном упорядоченном расположении взаимодействующих компонентов, составляющих ПС;
право вмешательства и приоритетного воздействия сверху вниз на компоненты нижних уровней;
взаимозависимость действий компонентов верхних уровней от реакций на воздействия и от функционирования компонентов нижних уровней, информация о которых передается верхним уровням.
В результате в иерархических структурах ПС образуются два потока взаимодействий между компонентами разных уровней: сверху вниз — координирующие и управляющие воздействия верхних уровней и снизу вверх — информация о состоянии и реализации предписанных сверху функций компонентами нижних уровней. Координируемые компоненты обычно имеют некоторую автономность поведения и подготовки локальных решений. Степень автономности компонентов и интенсивность координирующих воздействий устанавливаются в результате компромисса при выделении числа и размеров иерархических уровней. Взаимодействие компонентов в пределах уровня целесообразно максимально ограничивать, что позволяет упростить общее координирование компонентов и проводить его только по вертикали.
Менее наглядными являются иерархия данных, обрабатываемых ПС, и их взаимодействие с программными компонентами. Функциональная иерархия данных отражается расстоянием между расчетом или изменением переменной и ее использованием, или условной длительностью хранения неизменяемых значений переменной. Взаимодействие двух программных модулей может осуществляться так, что некоторые переменные используются только этими модулями. Такие обменные переменные имеют более широкую область применения и должны храниться все время, пока не будут вызваны взаимодействующие модули. Ряд переменных и массивов используется многими модулями и группами программ в комплексе — это глобальные переменные. Они характеризуются наиболее широким использованием и соответствуют высшему иерархическому уровню среди данных.
Анализ концепции, требований технического задания и технико-экономических оценок должен позволять выполнить предварительное структурное проектирование ПС и оценку вычислительных ресурсов, необходимых для решения основных функциональных задач. Повышению эффективности структурирования могут значительно способствовать заимствование из предыдущих проектов спецификаций прототипов, версий и отдельных компонентов ПС. Для обеспечения системного проектирования на этом этапе большое значение имеют графические методы визуализации технических решений и логического контроля проекта.
Характеристики внешней среды применения ПС и особенности реализующей ЭВМ в значительной степени определяют архитектуру и структуру применяемой операционной системы, средств контроля и организации вычислительного процесса. При разработке версий ПС для некоторой прикладной области целесообразно выбирать и унифицировать внешний интерфейс и операционную систему. Это обеспечивает многократное использование одних и тех же организующих программ, дисциплинирует структурное построение версий ПС и способствует унификации межмодульного интерфейса. Переход на новую операционную систему, так же как и переход на реализующую ЭВМ другого типа, может привести к необходимости некоторого изменения структурного построения ПС и базы данных. Это способно повлиять на возможность использования готовых компонентов, а следовательно, и на эффективность всей разработки.