Методологические основы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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