Анатолий Левенчук - Системное мышление

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

Заказать можно только модули, а ручка и ножевой блок у ножниц компоненты, а не модули. Модулями в ножницах будут только две половинки ножниц (а ещё винтик).

Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение.

Менеджеры же сначала внимают доводам инженеров, но потом… смотрят на ножницы в сборе, видят в действии (эксплуатации, operations) ручку и ножевой блок – и опять пытаются с ними сделать что-то по отдельности не в момент «спектакля» (когда ножницы в сборе и работают – режут), а в момент изготовления. Например, разделить работы по сборке ручки и ножевого блока, хотя при соединении половинок ножниц винтиком разделить работы по ручке и ножевому блоку принципиально невозможно. Или сделать каталог ручек и каталог ножевых блоков и потом пытаться заставить инженеров выпускать эти якобы «детали ножниц» в виде запчастей. Список ошибок и заблуждений тут бесконечен, и эти ошибки не прекратятся: менеджеры постоянно находят «ножевой блок» и «ручки» в инженерной документации и пытаются поступать с ними как со сборочными единицами.

Правда в том, что в ножницах разные стейкхолдеры усматривают две разные холархии: одна функциональной декомпозиции («аналитическая»), а вторая модульной сборки («синтетическая»):

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

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

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

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

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

В литературе для холархии часто используют просто термин «структура», но нужно помнить, что это именно холархия: отношения элементов в ней – это иерархия отношений «часть-целое» (is_part_of, composition, состава), а все другие отношения (специализации, классификации, предшествования во времени, взаимовлияния и т.д.) в этой «структуре» не учитываются.

На рисунке из стандарта IEC 81346—1 (а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09) «объект с функциональным аспектом» это компонента, «объект с продуктным аспектом» это модуль, а «объект как с продуктным, так и функциональным аспектом» – это модуль, сервис которого выполняет функцию компоненты.

Рассмотрим целевую систему, которую в начальный момент мы рассматриваем как компоненту А. Реализовать (realize) – это вынести «логический» объект-компоненту (роль) в физическую реальность модулей (исполнителей ролей). Первое что происходит – это функциональная декомпозиция: функция компоненты разбивается на более мелкие (на рисунке это B и другие четыре) и делается попытка выбрать для них модули, сервисы которых могут выполнить функции этих компонент. На рисунке видно, что на первом шаге декомпозиции это удаётся только для двух подфункций из шести. На следующем шаге это уже удаётся для всех подфункций, в то числе для подфункций компоненты B. Эта часть функциональной декомпозиции иногда называется функциональным анализом.Дальше мы должны из всех модулей, используя их интерфейсы для соединения, собрать целевую систему-модуль. Для сборки-модуля B на рисунке, реализующего функцию компоненты B это получается только в два шага – сначала собираются два промежуточных модуля, и только потом они объединяются. А на следующем шаге модуль B включается в состав модуля А, который реализует изначально задуманную функцию А. С этого момента функция и сервис совпадают, компонента и модуль совпадают. Эту часть проектирования системы как составления целой системы-модуля из её подмодулей называют модульный синтез.

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

Стандарт OMG Essence 120 120 http://www.omg.org/spec/Essence/ предлагает предлагает особый вид компонент – альфа(ALPHA). Альфа – это функциональный объект, контроль за изменением состояния которого позволяет оценивать степень продвижения проекта в работе с этой альфой. Мышление о том, «как проект работает» посвящено альфам, ролевым объектам, они имеют функцию/назначение, вменённые им в проекте человеком.

Этот же стандарт OMG Essence для модулей, физической реализации альф предлагает имя рабочий продукт(work product, иногда используемый синоним – «артефакт», artifact, т.е. предмет искусственного происхождения) – это конструктивный объект: то, над чем работаем, из чего проект «собран», что можно обнаружить в окружающем мире.

Альфа отличается от ранее встречавшихся нам 4D-функциональных объектов тем, что она бывает и абстрактным объектом – каким-то определением системы: требованиями, архитектурой, неархитектурной частью проекта/design. В проекте приходится следить как за функциональной частью разных описаний системы (определениями), так и за функциональной частью воплощения системы (компонентами).