ЧЕКМАРЕВ АНАТОЛИЙ

Глава 2. Сложные системы. Статическая и динамическая сложность. Подходы к проектированию сложных систем. Оценка сложности.

 

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

Естественно более сложный проект потребует больше времени и больших затрат. Что такое сложный или простой проект, сложная или простая система?

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

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

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

В широко известной книге Г.Буча «Объектно ориентированное проектирование» между простой и сложной системами проведена следующая граница: если система состоит из менее чем 8-ми объектов, то она простая. Более 8-ми – сложная. Здесь критерием выбрана способность мозга человека (наблюдателя) контролировать некоторое количество объектов единовременно.

Например, минимальное тактическое воинское подразделение (отделение) в количестве до 8 человек поддается эффективному контролю младшего командира в стрессовой динамичной ситуации. Увеличение количества подчиненных привело бы к недопустимому росту сложности контроля и потере управляемости, что было установлено длительной практикой.

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

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

Под статической – понимают количество объектов, входящих в систему и количество связей между ними.

Динамическая – учитывает изменяющиеся с течением времени процессы, происходящие в системе (между составляющими объектами) и с ее участием.

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

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

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

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

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

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

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

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

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

Эта методология явилась результатом развития таких теоретических и практических подходов как: анализ Декарта, теория хаоса, кибернетика, и др.

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

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

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

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

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

Описанный выше подход в инженерной методологии называют абстрагированием. В общем случае абстрагирование – это исключение из рассмотрения деталей системы (или ее связей), не важных с точки зрения проектировщика на текущем этапе работы.

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

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

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

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

Следующий подход – иерархия – является противоположностью и одновременно дополнением абстрагирования. При абстрагировании не рассматриваются внутренние детали системы и проектирование или анализ не могут быть полностью выполнены. Иерархия позволяет устранить этот недостаток. Рассмотрев систему в целом, мы можем выполнить ее декомпозицию на ограниченное количество подсистем, которые будут подвергнуты индивидуальному анализу в качестве «черных ящиков» на следующем этапе. Учитывая ограничения мыслительных способностей человека, не рекомендуется превышение количества этих элементов свыше 8-10. Это позволит сохранить представление об их взаимодействии в процессе работы.

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

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

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

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

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

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

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

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

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

Унификация архитектурных элементов (стандарт кирпича) в свое время обеспечила возможность создания высотных зданий.

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

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

В информационных технологиях применение унификации является не только обязательным, но и, возможно, наиболее ярко выраженным. В настоящее время большинство компьютеров взаимодействуют между собой на основе стандартного IP – протокола, предпринимаются постоянные усилия по приведению всех вычислительных систем в соответствие стандартизированной модели Open System Interconnection, идет систематическая работа по стандартизации форматов электронных документов и файлов хранения мультимедийных данных и т.д.

 

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

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

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

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

К основным в системном анализе и проектировании относят функциональные и структурные схемы.

Структурные – содержат информацию об элементах системы и наличии между ними взаимосвязи без указания функций связей и элементов.

Задача данных схем дать информацию о структуре системы на текущем уровне детализации.

Функциональные - несут более детализированную информацию. Их задача дать информацию о функциях связей и элементов.

На практике используется большое количество стандартных схем, иллюстрирующих протекание процессов. К таким стандартам относятся, например, IDEF0 – диаграммы, которые позволяют на стандартном широко применяемом графическом языке описывать последовательность выполнения операций (Activity Box) с дополнительными информационными элементами (дугами), обозначающими обрабатываемые объекты и ориентированными по отношению к функциональному блоку следующим образом:

•Верхняя сторона содержит информацию о значимом «Управлении» (Control), в роли которого может выступать, например, технологическая инструкция;

•Левая сторона имеет значение «Вход» (Input), при описании изготовления какой-либо детали токарем, например, будет содержать упоминание заготовки;

•Правая сторона имеет значение «Выход» (Output), т.е. результат операции;

•Нижняя сторона имеет значение «Механизм» (Mechanism), который в вышеприведенном случае должен будет именоваться как «токарь».

 

Стандарт описания процессов IDEF0 является развитием описания систем SADT (Structured Analysis and Design Teqnique). Первая версия вышла в 1981 году в рамках инициированной ВВС США программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing).

Первичная расшифровка стандартов IDEF - ICAM DEFinition. Обновленные редакции стандарта выпускаются Национальным институтом по стандартам и технологиям США (NIST).

Нотация IDEF0 предназначена для функционального описания процессов. При этом существуют дополнительные нотации: для описания внутренних информационных потоков в системе (IDEF1), для детализации реляционной структуры данных (IDEF1Х), процессов развития систем (IDEF2), для документирования техпроцессов (IDEF3), для объектно-ориентированного проектирования (IDEF4), для описания состава и функционирования систем (IDEF5) и т.д.

Несмотря на широкое применение, стандарты IDEF являются далеко не единственными.

Для проектирования и анализа автоматизированных систем на этапе первичного описания пользователем для передачи специалисту-программисту эффективным является применение use case диаграмм (переводят как «диаграмма прецедентов» или «диаграмма вариантов использования»).

Этот стандарт описания является частью Универсального языка моделирования (Universal modeling language - UML).

В общем виде диаграмма задает типы пользователей автоматизированной системы в виде так называемых экторов[1] (Actor), и связываемых с ними вариантов использования системы – use case. В качестве эктора по отношению к описываемой может выступать сторонняя автоматизированная система.

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

Use case – представление обладает рядом очевидных преимуществ:

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

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

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

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

• Являясь частью последовательной технологии описания UML, диаграмма позволяет обеспечивать последовательную многоэтапную детализацию описания с поддержкой целостности отражаемой графической информации на различных этапах: use case, диаграмма переходов (при реализации use case внутри системы), диаграмма классов и т.д.[2] Другими словами, данный вид графического описания поддерживает проектирование «сверху-вниз» и обеспечивает сохранение уровня детализации на соответствующем этапе проектирования.

   

  

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

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

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

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

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

 

 

---

 

[1] Часто встречающийся перевод с английского как «актер» не является удачным. Скорее по смыслу подходит «деятель».

 

[2] Полное описание языка UML и стандартов IDEF не является предметом данной книги