Важность функциональных рассмотрений целевой системы

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

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

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

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

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

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

Теперь представим инженера, которому маркетологи говорят, что ему нужно будет решить задачу химического синтеза, но непонятно ещё какую. И они когда-нибудь потом, но вот не прямо сейчас наймут химика, который всё уточнит. Инженер соглашается и берётся за дело: ему сразу понятно, что нужны будут реакторы и трубы. Реакторов непонятно сколько, ибо непонятно, сколько там в синтезе будет химических реакций. Поэтому лучше бы этих реакторов было побольше. Он выбирает цифру 4, как «не очень мало, но и ещё не очень дорого», догадывается, что в этом синтезе может быть хитрая эндотермическая реакция, но сам он для такой реакции реактор вряд ли спроектирует. Так что этот «хитрый реактор» он отдаёт проектировать внешним контракторам и честно об этом пишет. Хотя контракторы и спрашивали, что там с массами и температурой, ответ пока никто не может дать, поэтому контракт планируется без разговора о требованиях — но контрактор, разумеется, от заказа не отказывается и говорит, что «сделаю любой реактор». Слово «любой» никого не отпугивает, ибо нет химика, который бы сказал, что же будет в этом реакторе происходить. Есть только инженеры по железу, хорошо разбирающиеся в марках стали и сварке, и маркетологи, беседующие с врачами и фармацевтами.

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

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

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

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

Мыслить только про конструкции нельзя. Отсутствие мышления о функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о функциональности заметно только в случае наличия системного мышления — оно позволяет заметить то, о чём вы забыли подумать, управляет вашим вниманием.