Письмо 02 - Сложные системы

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

Наверное, имеет смысл сказать ещё несколько слов о сложных системах, создание которых становится возможным на основе объектной технологии. Г. Буч в своей книге «Объектно-ориентированный анализ и проектирование с примерами приложений на C++» со ссылкой на Брукса (Brooks, F. April 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer vol. 20(4), p12.) отмечает, что «сложность вызывается четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; трудностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем» [стр. 22]. Далее Г. Буч, со ссылкой на Куртуа, (Courtois, P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol. 28(6), p. 596) выделяет пять признаков сложной системы [стр. 29-30]:

1. Сложные системы часто являются иерархическими и состоят из взаимосвязанных подсистем, которые в свою очередь могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровня.
2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большей степени оставляется на усмотрение исследователя.
3. Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять «высокочастотные» взаимодействия внутри компонентов от «низкочастотной» динамики взаимодействия между компонентами.
4. Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных.
5. Любая работающая сложная система является результатом развития работавшей более простой системы… Сложная система, спроектированная с «нуля», никогда не заработает. Следует начинать с работающей простой системы.

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

Любая сложная система состоит из некоторого количества элементарных компонент. Типов компонент не может быть много, но экземпляры этих компонент могут произвольно комбинироваться, отражая многообразие мира. Здесь вполне уместно вспомнить, что все многообразие цветов и оттенков обеспечивается комбинацией всего из трёх основных цветов; всё многообразие предприятий, не зависимо от их специализации, формы собственности, географического положения и т.п., обеспечивается комбинацией трёх составных частей: люди, оборудование и материалы. Все механизмы представляют собой комбинации групп Ассура, а все вещества состоят из элементов таблицы Менделеева. Таких примеров можно привести множество для любой предметной области, но при этом важно отметить, что выбор элементарных составляющих не может быть произвольным или случайным. От правильности выбора элементарных составляющих зависит принципиальная возможность создания системы и её сложность. Но данный тезис реально изменяет понятие сложности системы для любой предметной области. Система сложна настолько, насколько она непонятна, и непонятна настолько, насколько нам сложно вычленить её элементарные компоненты и определить связи между ними.

Сложная система, как было отмечено ранее, отличается сложностью управления, то есть сложностью связей между компонентами. Каждый уровень управления обладает собственной логикой, которая не зависит от логики управления других уровней. Взаимодействие между уровнями управления в любой (не только программной) сложной системе основано на декларированном интерфейсе каждого уровня. Создание интерфейсов и связей на каждом уровне управления представляет собой отдельную задачу и требует отдельных проектных решений. Создание и развитие каждого уровня может и должно вестись параллельно с созданием и развитием других уровней. Развитие любого уровня начинается с декларации его интерфейса и только после определения интерфейса и увязки его с интерфейсами смежных уровней управления, можно переходить к реализации всех уровней. Интерфейс представляет собой формальную спецификацию возможностей данного логического уровня. Этот тезис переформулирует положение о трудностях, связанных с процессом разработки. Трудность разработки зависит от того, насколько точно определены основные логические уровни и того, насколько хорошо формализованы интерфейсы всех уровней.

Как следствие, сложная система может создаваться с «нуля» и развиваться произвольно долго, расширяя, углубляя и совершенствуя свои функциональные возможности. Но для выполнения этого требования необходимо тщательное соблюдение инкапсуляции, дабы отдельные компоненты системы можно было безболезненно заменять непосредственно во время её работы. Таким образом, инкапсуляция обеспечивает развитие и модифицируемость, то есть, гибкость системы. Но об этом речь пойдёт ниже.

Претензии к неудовлетворительным способам описания поведения больших дискретных систем нельзя воспринимать однозначно. До тех пор, пока делаются попытки описания системы в целом, без разделения её на отдельные уровни (деление на горизонтальные уровни) и подсистемы/компоненты/объекты (деление по вертикали), такие претензии безусловно оправданы. Однако тщательное деление и разработка логики каждого уровня не только серьёзно упрощает задачу, но и выявляет несостоятельность этих претензий.

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

1. основана на ограниченном числе базовых процессов, определяющих существо системы;
2. не имеет детального формального описания;
3. обладает выраженной иерархичностью;
4. находится в постоянном развитии и, как следствие, не имеет завершённого состояния;
5. разложима на более простые составляющие, вплоть до элементарных;
6. определяется сложностью связей между её составляющими;
7. выполняет только функции управления по отношению к составляющим;

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

Теперь осталось показать, что объектная технология хорошо подходит для разработки таких систем. Для этого необходимо сделать описание основных положений, на которых основана объектная технология.