Приемы работы со сложностью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.1. Пример изображения графа.

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

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

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

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

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

Диаграммы процессов IDEF. На практике используется большое количество стандартных схем, иллюстрирующих протекание процессов. К таким стандартам относятся, например, IDEFO — диаграммы, которые позволяют на стандартном широко применяемом графическом языке описывать последовательность выполнения операций (англ, activity box) с дополнительными информационными элементами (дугами), обозначающими обрабатываемые объекты и ориентированными по отношению к функциональному блоку следующим образом (рис. 2.2):

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

зо.

Рис. 2.2. Изображение элемента IDEF.

Стандарт описания процессов IDEFO является развитием описания систем SADT (от англ, structured, analysis and design teqnique). Первая версия вышла в 1981 г. в рамках инициированной ВВС США программы автоматизации промышленных предприятий /САМ (от англ, integrated computer aided manufacturing).

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

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

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

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

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

В общем виде диаграмма задает типы пользователей автоматизированной системы в виде так называемых акторов^[1] (англ, actor), и связываемых с ними вариантов использования системы — use case (рис. 2.3).

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

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

Рис. 2.3. Пример изображения схемы use case.

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

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

Диаграммы ВРМ (от англ, business process modelling). Часто при проектировании автоматизированных систем используется процессный подход. Этот подход предполагает, что процесс — это заданная последовательность операций, выполняемых процессными ролями, имеющая вход, результат, временные и стоимостные характеристики.

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

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

Для решения подобных задач международный некоммерческий консорциум Object Management Group, организованный в 1989 г. крупнейшими производителями программного обеспечения, принял в 2006 г. нотацию описания бизнес-процессов Business Process Model and Notation (BPMNj.

Нотация включает основные элементы, представленные на рис. 2.4.

Рис. 2.4. Пример изображения схемы ВРМ.

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

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

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

Задание (англ, task) — это единица работы, элементарное действие в процессе.

Свернутый подпроцесс (англ, collapsed subprocess) является составным действием, но скрывает детали реализации процесса.

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

• • оператор исключающего «или», управляемый данными (англ, databased exclusive gateway). Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток;
• • оператор исключающего «или», управляемый событиями (англ. event-based exclusive gateway), направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений;
• • оператор включающего «или» (англ, inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток;
• • оператор «и» (англ, parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей и лишь затем активирует выходной поток.

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

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

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

Артефакты служат для отображения в схеме дополнительной информации:

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

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

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

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

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

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

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

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

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

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