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

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

Гибкость модификации и расширяемость комплексов программ при их совершенствовании обеспечиваются рядом принципов и правил структурного построения ПС и их компонентов, а также взаимодействия между ними. Эти правила направлены на стандартизацию и унификацию структуры и взаимодействия компонентов ПС разного ранга и назначения в пределах проблемной области. Некоторая часть принципов и правил имеет достаточно общий характер и может применяться практически всегда. Другая часть отражает проблемную и/или машинную ориентированность класса ПС и подлежит отработке при системном проектировании для эффективного применения в соответствующей области. Основные принципы и правила структурирования ПС и БД можно объединить в группы, которые отражают:

- стандартизированную структуру целостного построения ПС и/или БД определенного класса;

- унифицированные правила структурного построения функциональных программных компонентов и модулей;

- стандартизированную структуру базы данных, обрабатываемых программами;

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

- унифицированные правила организации и структурного построения межмодульных интерфейсов программных компонентов;

- унифицированные правила внешнего интерфейса и взаимодействия компонентов ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса, защиты и контроля системы.

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

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

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

- эффективные и удобные средства описания свойств и особенностей структуры создаваемой системы – нотации описания;

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

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

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

- соответствие функций и структуры ПС аппаратной и операционной среде, их ресурсам и интерфейсам;

- совместимость ПС с другими системами по источникам и потребителям информации;

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

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

- состав, структура и способы обмена данными между функциональными компонентами и внешней средой ПС;

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

- контроль, хранение, обновление, защита и восстановление программ и данных;

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

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

Структурное проектирование программных средств основано на модульном принципе. Многоуровневое, иерархическое построение сложных программных комплексов позволяет ограничивать и локализовать на каждом из уровней соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные и информационные модули (модули данных). Эти компоненты объединяются в группы программ определенного функционального назначения с автономной целевой задачей. Несколько групп функциональных программ образуют комплекс программ. В особо сложных случаях возможно создание программного средства из нескольких взаимодействующих комплексов. Всем иерархическим системам (в частности, ПС) присущ ряд общих свойств, важнейшими из которых являются:

- вертикальная соподчиненность, заключающаяся в последовательном упорядоченном расположении взаимодействующих компонентов, составляющих ПС;

- право вмешательства и приоритетного воздействия сверху вниз на компоненты нижних уровней;

- взаимозависимость действий компонентов верхних уровней от реакций на воздействия и от функционирования компонентов нижних уровней, информация о которых передается верхним уровням.

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

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

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

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

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

Повторная применимость – является еще одним качеством структуры программного продукта, на которое заметно воздействует принцип возможности изменений. Компонент является многократно применимым, если он может быть непосредственно использован для производства нового продукта или версии. На практике компонент может претерпеть некоторые изменения прежде, чем будет использован повторно. Отсюда многократное использование можно рассматривать как эволюционность системной структуры ПС на уровне компонентов. Если можно предвидеть изменения контекста, в который будет встроен программный компонент, то и компонент можно спроектировать таким образом, что изменения будут им учтены.