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

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

-оптимизации структуры КП как с точки зрения максимального использования ресурсов ЭВМ, так и с точки зрения эффективности их проектирования и отладки;

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

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

-контроля достоверности выполнения функциональных программ и адаптации КП при изменении характеристик внешних абонентов или управляющей ЭВМ;

-обеспечения простой корректировки КП при изменении в некоторых пределах характеристик внешних абонентов и гибкой модернизируемости ПС.

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

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

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

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

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

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

-обеспечения испытаний программных компонент и всего КП;

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

-В целом структурные и технологические проблемы проектирования ПС можно объединить в единую проблему разработки методов и автоматизированных систем для проектирования сложных /С/7 {см. гл. 6). К/ проектированию также необходим системный комплексный подход с учетом основных особенностей и критериев эффективности, характерных для создания сложных систем. Автоматизированные системы проектирования программ могут превосходить по сложности создаваемые с их помощью ПС. Однако возможность широкого применения систем проектирования для различных ПС делает рентабельной разработку автоматизированных систем проектирования программ.

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

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

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

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

Блочно-иерархический подход к созданию сложных систем

Большинство сложных систем как в природе, так и в технике имеет иерархическую внутреннюю структуру. Это связано с тем, что обычно связи элементов сложных систем различны как по типу, так и по силе, что и позволяет рассматривать эти системы как некоторую совокупность взаимозависимых подсистем. Внутренние связи элементов таких подсистем сильнее, чем связи между подсистемами.

В свою очередь, используя то же различие связей, можно каждую подсистему разделить на

подсистемы и т. д. до самого нижнего «элементарного» уровня, причем выбор уровня,

компоненты которого следует считать элементарными, остается за исследователем. На

элементарном уровне система, как правило, состоит из немногих типов подсистем, по-разному

скомбинированных и организованных. Иерархии такого типа получили название «целое-часть».

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

причем из-за более сильных внутренних связей особенности системы в основном обусловлены

отношениями между ее частями, а не частями как таковыми.

В природе существует еще один вид иерархии - иерархия «простое-сложное» или иерархия

развития (усложнения) систем в процессе эволюции. В этой иерархии любая функционирующая

система является результатом развития более простой системы. Именно данный вид иерархии

реализуется механизмом наследования объектно-ориентированного программирования.

На этих свойствах иерархических систем строится блочно-иерархический подход к их исследованию или созданию. Этот подход предполагает сначала создавать части таких объектов (блоки, модули), а затем собирать из них сам объект.

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

При создании очень сложных объектов процесс декомпозиции выполняется многократно:

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

сравнительно легко разработать. Данный метод разработки получил название пошаговой

детализации.

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

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

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

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

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

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

используют свои формы документации и свои модели, отражающие сущность процессов,

выполняемых каждым блоком. Так для объекта в целом, как правило, удается сформулировать

лишь самые общие требования, а блоки нижнего уровня должны быть специфицированы так,

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

больше блок, тем более абстрактным должно быть его описание.

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

локальной оптимизацией (в отличие от глобальной оптимизации характеристик объектов, которая

для действительно сложных объектов не всегда возможна).

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

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

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

Помимо того, что использование блочно-иерархического подхода делает возможным создание сложных систем, он также:

• упрощает проверку работоспособности, как системы в целом, так и отдельных блоков;

• обеспечивает возможность модернизации систем, например, замены ненадежных блоков с

сохранением их интерфейсов.

Необходимо отметить, что использование блочно-иерархического подхода применительно к программным системам стало возможным только после конкретизации общих положений подхода и внесения некоторых изменений в процесс проектирования. При этом структурный подход учитывает только свойства иерархии «целое-часть», а объектный - использует еще и свойства иерархии «простое-сложное».