Компонентный анализ и модульный синтез

 

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

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

 

 

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

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

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

 

Альфы и рабочие продукты

 

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

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

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

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

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

 

 

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

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

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

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

В реальном мире мы видим артефакты «яблоки» и определённые дела с этими артефактами, например, «съесть яблоки», «сосчитать яблоки». Альфы представляют собой те объекты, которые описываются дисциплиной (теорией) – «количество предметов» и «сосчитать предметы», если вернуться к примеру со счётом яблок. Альфа тут – «предмет», а не «яблоко»! Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком варианте[121]:

Пришла в… школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и ещё пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь – раз—два—три – три яблока, а здесь вот – раз—два—три—четыре—пять – пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий – рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот—де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие – это яблоки из задачи». – «Да, а что?» – «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладёте реальные яблоки – что с ними надо делать? Их надо есть. А чтобы считать, нужны рисуночки.

Вот ещё про то же самое[122]:

– Мы займёмся арифметикой… У вас в кармане два яблока…

Буратино хитро подмигнул:

– Врёте, ни одного…

– Я говорю, – терпеливо повторила девочка, – предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?

– Два.

– Подумайте хорошенько.

Буратино сморщился, – так здорово подумал.

– Два…

– Почему?

– Я же не отдам Некту яблоко, хоть он дерись!

– У вас нет никаких способностей к математике, – с огорчением сказала девочка.

Про физическое тело мы знаем, что при наличии силы тяжести они летят по параболе. Ускорения и масса тоже у физических тел. Если кинуть камень и не суметь соотнести его с физическим телом, то нельзя сказать, что он полетит по параболе! Нет таких учебников, в которых описываются полёты именно камней! Ричард Фейнман в своих заметках по преподаванию физики ровно об этом сожалел: по всему миру ученики физики не могут сопоставить отличные знания из учебника явлениям окружающего мира[123].

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

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

• Ничего не понимают, ибо неспособны соотнести материал книги с окружающим их миром. Действительно, в их инженерных, менеджерских, культурных проектах нет никаких альф. А в книге нет ничего, что есть в их проектах. Более того, каждый проект уникальный – в них ведь вообще нет ничего общего, а книга одна и та же для этих самых разных проектов! И эти проекты в книге не описаны, примеры из них не приведены.

• Всё понимают про приводимые в книге примеры, а также про проекты однокурсников и коллег по работе, но при этом ничего не понимают про свои собственные проекты. Конечно, ибо чужие проекты – это «проекты из чужой задачи» (помним, «яблоки из задачи – их можно считать»), а свои проекты – это «реальные мои проекты» («яблоки из жизни», их нужно есть!).

• Всё понимают и про свои проекты, и про проекты коллег. Но ничего из понимаемого не делают, ибо системное мышление изучается не для того, чтобы его применять, а «для самообразования и развития», «для сдачи зачёта» и т. д. Применять знания мешают начальники, текучка, лень, отсутствие единомышленников, помогать применять знания некому.

• Применяют материал книги в своих проектах, ибо так работать оказывается качественней, легче и в конечном итоге быстрее. Очень часто это происходит только через год-два после знакомства с книгой. В первом разделе нашей книги об этом было подробно сказано.

 

Альфы

 

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

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

Альфы (alphas) – это функциональные (выполняющие определённую функцию, играющие определённую роль, идеальные) объекты, по которым мы судим о продвижении (progress, «как много мы уже сделали?») и здоровье (health, «в проекте всё идёт хорошо») проекта.

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

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

Например, учимся думать о «требованиях» – а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве «в реале»: спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т. д.

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

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

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

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

Формально (то есть в стандарте OMG Essence[124]) ALPHA – это аббревиатура, Abstract-Level Progress Health Attribute, но неформально это просто способ указать на функциональный элемент/компоненту проекта. Аббревиатура про health attribute была для альфы подобрана задним числом, а слово alpha пишут поэтому маленькими буквами.